objectbridge-developers — public list for developer issues

AW: [OJB-developers] SQLGenerator

[Mahler T. <tho...@it...>]

Hi Oleg,

> -----Ursprungliche Nachricht-----
> Von: Oleg Nitz [mailto:on...@uk...]
> Gesendet: Donnerstag, 2. Mai 2002 16:36
> An: obj...@li...
> Betreff: [OJB-developers] SQLGenerator
> 
> 
> Hi,
> 
> I started to work on the "OQL Self Joins" issue
>   
> http://sourceforge.net/forum/forum.php?thread_id=655922&forum_id=43066
> so I am looking at the SQLGenerator stuff, and its 
> capabilities seem a bit 
> restricted. Please, confirm the following statements
> 1) OJB supports only databases that support SQL-92 JOIN 
> syntax (INNER JOIN, 
> LEFT OUTER JOIN). 

Right !

> Thus Sybase ASE and MS SQL Server aren't supported, since 
> they don't support 
> SQL-92 JOIN syntax AFAIK. Does Oracle support it? Not sure.

AFAIK Oracle 8i doesn't but 9i does.

> I suppose that generating of join syntax should be delegated 
> to Platform 
> implementations. 

I agree.

> 2) OJB doesn't support queries on columns with path longer than 1, 
> i.e. it successfully handles
>             crit.addEqualTo("source.name", "A");
> but fails on 
>             crit.addGreaterThan("source.location.x", new Integer(0));
> 

Oh, I thought this was possible. If this does not work it should be fixed !

> I can try to solve these issues too.

That would be great !

Thanks,

Thomas

> 
> Regards,
>  Oleg
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download 
> mirrors. We supply
> the hardware. You get the recognition. Email Us: 
> ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

RE: [OJB-developers] SQLGenerator

[Charles A. <cha...@hp...>]

MS SQL 7 seems to support SQL-92 JOIN syntax: the following is the syntax of
the FOR clause from the transact-sql help file...

[ FROM {<table_source>} [,...n] ]

<table_source> ::=
	table_name [ [AS] table_alias ] [ WITH ( <table_hint> [,...n]) ]
	| view_name [ [AS] table_alias ]
	| rowset_function [ [AS] table_alias ]
	| derived_table [AS] table_alias [ (column_alias [,...n] ) ]
	| <joined_table>

<joined_table> ::=
	<table_source> <join_type> <table_source> ON <search_condition>
	| <table_source> CROSS JOIN <table_source>
	| <joined_table>
 
<join_type> ::=
	[ INNER | { { LEFT | RIGHT | FULL } [OUTER] } ]
	[ <join_hint> ]
	JOIN

Cheers,

Charles.

> -----Original Message-----
> From: Oleg Nitz [mailto:on...@uk...]
> Sent: 02 May 2002 15:36
> To: obj...@li...
> Subject: [OJB-developers] SQLGenerator
> 
> 
> Hi,
> 
> I started to work on the "OQL Self Joins" issue
>   
> http://sourceforge.net/forum/forum.php?thread_id=655922&forum_id=43066
> so I am looking at the SQLGenerator stuff, and its 
> capabilities seem a bit 
> restricted. Please, confirm the following statements
> 1) OJB supports only databases that support SQL-92 JOIN 
> syntax (INNER JOIN, 
> LEFT OUTER JOIN). 
> Thus Sybase ASE and MS SQL Server aren't supported, since 
> they don't support 
> SQL-92 JOIN syntax AFAIK. Does Oracle support it? Not sure.
> I suppose that generating of join syntax should be delegated 
> to Platform 
> implementations. 
> 2) OJB doesn't support queries on columns with path longer than 1, 
> i.e. it successfully handles
>             crit.addEqualTo("source.name", "A");
> but fails on 
>             crit.addGreaterThan("source.location.x", new Integer(0));
> 
> I can try to solve these issues too.
> 
> Regards,
>  Oleg
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download 
> mirrors. We supply
> the hardware. You get the recognition. Email Us: 
> ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 


This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.

Re: [OJB-developers] SQLGenerator

[Henri Y. <ba...@ge...>]

I'm not much of a DB guy, but I am pretty sure we're using the SQL-92 JOIN
syntax in Oracle 9i. I think 8 and before, maybe 8i didn't support that.

On Thu, 2 May 2002, Oleg Nitz wrote:

> Hi,
>
> I started to work on the "OQL Self Joins" issue
>   http://sourceforge.net/forum/forum.php?thread_id=655922&forum_id=43066
> so I am looking at the SQLGenerator stuff, and its capabilities seem a bit
> restricted. Please, confirm the following statements
> 1) OJB supports only databases that support SQL-92 JOIN syntax (INNER JOIN,
> LEFT OUTER JOIN).
> Thus Sybase ASE and MS SQL Server aren't supported, since they don't support
> SQL-92 JOIN syntax AFAIK. Does Oracle support it? Not sure.
> I suppose that generating of join syntax should be delegated to Platform
> implementations.

[OJB-developers] SQLGenerator

[Oleg N. <on...@uk...>]

Hi,

I started to work on the "OQL Self Joins" issue
  http://sourceforge.net/forum/forum.php?thread_id=655922&forum_id=43066
so I am looking at the SQLGenerator stuff, and its capabilities seem a bit 
restricted. Please, confirm the following statements
1) OJB supports only databases that support SQL-92 JOIN syntax (INNER JOIN, 
LEFT OUTER JOIN). 
Thus Sybase ASE and MS SQL Server aren't supported, since they don't support 
SQL-92 JOIN syntax AFAIK. Does Oracle support it? Not sure.
I suppose that generating of join syntax should be delegated to Platform 
implementations. 
2) OJB doesn't support queries on columns with path longer than 1, 
i.e. it successfully handles
            crit.addEqualTo("source.name", "A");
but fails on 
            crit.addGreaterThan("source.location.x", new Integer(0));

I can try to solve these issues too.

Regards,
 Oleg

[OJB-developers] serializable repository

[Jakob B. <jbr...@ho...>]

hi,

after updating from cvs, the test case AllTests has a problem serializing
the repository. i get a NotSerializableException for reflect.field.

jakob

.[BOOT] INFO: OJB.properties:
file:/D:/Java/eclipse_0425/workspace/ojb-1-0/src/test/test/ojb/OJB.propertie
s
[BOOT] INFO: loading XML took 691 msecs
[DEFAULT] ERROR: Could not write to
fileD:\Java\eclipse_0425\workspace\ojb-1-0\src\test\test\ojb\repository.xml.
serialized
java.lang.reflect.Field
java.io.NotSerializableException: java.lang.reflect.Field
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1098)
at
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStre
am.java:456)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at java.util.Hashtable.writeObject(Hashtable.java:764)
at java.lang.reflect.Method.invoke(Native Method)
at
java.io.ObjectOutputStream.invokeObjectWriter(ObjectOutputStream.java:1864)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1210)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at
ojb.broker.metadata.RepositoryPersistor.serialize(RepositoryPersistor.java:3
87)
at
ojb.broker.metadata.RepositoryPersistor.readFromFile(RepositoryPersistor.jav
a:209)
at
ojb.broker.metadata.DescriptorRepository.getInstance(DescriptorRepository.ja
va:379)
at
ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Pe
rsistenceBrokerFactoryDefaultImpl.java:128)
at
ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Pe
rsistenceBrokerFactoryDefaultImpl.java:170)
at
ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(PersistenceBroke
rFactory.java:65)
at
test.ojb.broker.PersistenceBrokerTest.setUp(PersistenceBrokerTest.java:141)
at junit.framework.TestCase.runBare(TestCase.java:138)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:131)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at junit.textui.TestRunner.doRun(TestRunner.java:74)
at junit.textui.TestRunner.start(TestRunner.java:234)
at junit.textui.TestRunner.main(TestRunner.java:112)
at test.ojb.broker.AllTests.main(AllTests.java:25)

Re: [OJB-developers] Bug in OQLQueryImpl

[Jakob B. <jbr...@ho...>]

hi thomas,

i fixed this bug long time ago, but it may still be on the todo-list

public void bind(Object parameter) throws
org.odmg.QueryParameterCountInvalidException,
org.odmg.QueryParameterTypeInvalidException
{
    ...
    // BRJ: bind is called twice for between
    if (crit instanceof BetweenCriteria && !crit.isBound())
        getBindIterator().previous();
    ...

jakob


----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Matthew Baird" <ma...@so...>
Cc: <obj...@li...>
Sent: Thursday, May 02, 2002 6:58 AM
Subject: Re: [OJB-developers] Bug in OQLQueryImpl


> fixed it !
>
> There have been similar bugs with the BetweenCriteria, which takes two
> parameters.
> Jakob did you found a fix for this in the meantime ?
>
> Thanks,
>
> Thomas
>
> Matthew Baird wrote:
>
>  > During the criteria flattening, to create the bind iterator, all
> criteria,
>  > regardless of if they have actual bindable criteria or not, are added
> to the
>  > bind iterator. I spent some time trying to find a rather nasty bug
> where my
>  > criteria wasn't getting bound correctly and came up with this:
>  >
>  >
>  >     private Vector flatten(Criteria crit, Vector acc)
>  >     {
>  >         Enumeration e = crit.getElements();
>  >         while (e.hasMoreElements())
>  >         {
>  >             Object o = e.nextElement();
>  >             if (o instanceof Criteria)
>  >             {
>  >                 Criteria pc = (Criteria) o;
>  >                 flatten(pc, acc);
>  >             }
>  >             else
>  >             {
>  >              // null criteria doesn't have a binding variable.
>  >              if (!(o instanceof ojb.broker.query.NullCriteria))
>  >              {
>  >                  SelectionCriteria c = (SelectionCriteria) o;
>  >                  acc.add(c);
>  >                 }
>  >             }
>  >         }
>  >         return acc;
>  >     }
>  >
>  > null doesn't have a binding variable, so we skip it. Are there other
>  > criteria types that don't have a bind variable ($X).
>  >
>  > Thomas, could you commit this fix? I'm still getting my CVS access set
up
>  > (and figuring out cvs :))
>  >
>  >
>  >
>  >
>  >
>
>
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: [OJB-developers] Lots of class mappings in OJB Problem

[Thomas M. <tho...@ho...>]

Hi Matthew,

I just fixed all these bugs. The whole OJB TestSuite now passes with
using the PropertyFieldImpl. I also got everything running with the
using the repository serialization.

There is now a flag in OJB.properties that can be used to enable loading
of the serialized repository:

useSerializedRepository=true

I noticed that using XML and PropertyFieldImpl takes nearly 2 times
longer than using PersistentFieldDefaultImpl.

If you switch useSerializedRepository to true loading takes almost the
same time.

I hope this helps to solve your "many classes" problem.


Thomas



Matthew Baird wrote:

 > Turns out PropertyDescriptor is not marked serializable.
 >
 > so I marked it transient, although this will have problems I'm sure.
 >
 > After looking at the PropertyFieldDefaultImpl, the "Field" is marked
 > transient. Won't this cause problems when you deserialize the class 
and try
 > to use it?
 >
 > m
 >
 > 14:26:21,340 INFO  [STDOUT] Could not write to
 > fileC:\jboss-3.0.0RC1_tomcat-4.0.3\bin\repository.xml.serialized
 > 14:26:21,340 INFO  [STDOUT] java.beans.PropertyDescriptor
 > 14:26:21,340 ERROR [STDERR] java.io.NotSerializableException:
 > java.beans.PropertyDescriptor
 > 14:26:21,340 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
 > 14:26:21,340 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
 > 14:26:21,350 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
 > 14:26:21,360 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
 > 14:26:21,360 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
 > 14:26:21,370 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
 > 14:26:21,370 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputArray(ObjectOutputStream.java:1098)
 > 14:26:21,370 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.checkSubstitutableSpecialClasses(ObjectOutputStre
 > am.java:4
 > 56)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
 > 14:26:21,370 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
 > 14:26:21,370 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
 > 14:26:21,370 ERROR [STDERR]     at
 > java.util.Hashtable.writeObject(Hashtable.java:764)
 > 14:26:21,370 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Native
 > Method)
 > 14:26:21,370 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.invokeObjectWriter(ObjectOutputStream.java:1864)
 > 14:26:21,380 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1210)
 > 14:26:21,380 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
 > 14:26:21,380 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
 > 14:26:21,380 ERROR [STDERR]     at
 > 
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
 > 14:26:21,380 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
 > 14:26:21,380 ERROR [STDERR]     at
 > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
 > 14:26:21,380 ERROR [STDERR]     at
 > 
ojb.broker.metadata.RepositoryPersistor.serialize(RepositoryPersistor.java:3
 > 45)
 > 14:26:21,380 ERROR [STDERR]     at
 > 
ojb.broker.metadata.RepositoryPersistor.readFromFile(RepositoryPersistor.jav
 > a:183)
 > 14:26:21,380 ERROR [STDERR]     at
 > 
ojb.broker.metadata.DescriptorRepository.getInstance(DescriptorRepository.ja
 > va:379)
 > 14:26:21,380 ERROR [STDERR]     at
 > 
ojb.broker.ta.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(Pe
 > rsistence
 > BrokerFactoryDefaultImpl.java:255)
 >
 >
 >
 > -----Original Message-----
 > From: Thomas Mahler [mailto:tho...@ho...]
 > Sent: Friday, April 26, 2002 2:07 PM
 > To: Matthew Baird
 > Cc: 'obj...@li...'
 > Subject: Re: [OJB-developers] Lots of class mappings in OJB Problem
 >
 >
 > Hi Matthew,
 >
 > sorry for answering late, I had been on a 3 day business trip.
 >
 > Matthew Baird wrote:
 >
 >
 >>My project has between 200 and 250 mapped classes, and is taking a *long*
 >>time for OJB to initialize. Is there any way to speed this up?
 >>
 >
 >
 > I don't think that we speed up the parsing process much. It's already
 > implemented with SAX, which is much faster than DOM and there is not
 > much to improve here.
 >
 > But to speed up your "lots of classes" scenario I just checked in a
 > little hack into the CVS (I made changes to ClassDescriptor,
 > DescriptorRepository and RepositoryPersistor):
 >
 > It now works like follows:
 > 1. The Persistory is asked to read in a Repository from a file (say
 > "repository.xml").
 > 2. The persistor checks if a file "repository.xml.serialized" exists.
 >
 > 2a) if this file exists, the Persistor deserializes a
 > DescriptorRepository instance from this file.
 > This instance is returned and thus the slow XML parsing of
 > "repository.xml" is avoided.
 >
 > 2b) if not, it performs the ordinary SAX parsing of the "repository.xml"
 > file. The resulting repository object is immediately serialized to the
 > file "repository.xml.serialized". Thus it can be used on the next
 > application startup.
 >
 > I assume that Java-deserialization is much faster than SAX Parsing.
 > How long does the Application startup take with this solution for your
 > scenario?
 >
 > I will polish up things a little, but I think it is OK to use this stuff
 > already.
 >
 > cheers,
 >
 > Thomas
 >
 >
 >
 >>regards,
 >>Matthew
 >>
 >>_______________________________________________
 >>Objectbridge-developers mailing list
 >>Obj...@li...
 >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >>
 >>
 >>
 >>
 >>
 >
 >
 >
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >
 >
 >
 >

Re: [OJB-developers] One more question

[Thomas M. <tho...@ho...>]

Hi,

Joa...@tp... wrote:

 >>>[snip Exception chaining with JDK 1.3-compatibility using Reflection]
 >>>
 >>>
 >>This is definitely a good idea! Does it work with JDK 1.2 too?
 >>If so you should commit it !
 >>
 >
 > I commited it before you answered. Mea culpa. Today I checked wether it
 > works with JDK 1.2 and it doesn, but other parts of OJB don't.

 > DefaultConnectionFactory used JNDI, which was not part of JDK1.2. I've
 > added jndi.jar (which is only 96kb) to the repository.


Thanks ! The jndi.jar must have been on my classpath. I never had any
compile problems with jdk 1.2 !

 > Additionally the
 > reversedb GUI doesn't compile with 1.2


Yes, that's right. I think it's important to have the operational kernel
JDK 1.2 as there are production environments requiring JDK1.2.
I don't see why a compile-time tool must stick to JDK 1.2

 > so I just added it to excludes in
 > build.properties (localy only, of course). We should either add
 > build.properties to the preprocessing (which I don't think is a good 
idea)
 > or just tell JDK 1.2 users to add it to build.properties manually (not a
 > perfect solution either).


it's not perfect, but it's only for a small number of users...


 >
 > We could move the tools to a seperate ant-target, so the default 
build will
 > work with JDK 1.2 and reversedb & co would be in another target (I don't
 > think that making reversedb work with 1.2 is worth the trouble).
 >


that's a good idea!


 >
 >>If not we should have some more "nit-picking" discussions ;-)
 >>
 >
 > *g* I like those ...
 >
 >
 >>cheers,
 >>
 >>Thomas
 >>
 >
 > btw, could we modify the mailing list setup so that replies go to the 
list
 > by default? Sometimes I reply to posts on this mailinglist only to 
see that
 > I sent the reply to the poster instead of the mailing list, which 
prevents
 > discussions to stay on the list.
 >


Mhh, I don't know if this is possible. It's just the SF way of life...

cu,

Thomas


 > regards
 > Joachim Sauer
 >
 >
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >
 >
 >
 >

Re: [OJB-developers] Bug in OQLQueryImpl

[Thomas M. <tho...@ho...>]

fixed it !

There have been similar bugs with the BetweenCriteria, which takes two
parameters.
Jakob did you found a fix for this in the meantime ?

Thanks,

Thomas

Matthew Baird wrote:

 > During the criteria flattening, to create the bind iterator, all 
criteria,
 > regardless of if they have actual bindable criteria or not, are added 
to the
 > bind iterator. I spent some time trying to find a rather nasty bug 
where my
 > criteria wasn't getting bound correctly and came up with this:
 >
 >
 >     private Vector flatten(Criteria crit, Vector acc)
 >     {
 >         Enumeration e = crit.getElements();
 >         while (e.hasMoreElements())
 >         {
 >             Object o = e.nextElement();
 >             if (o instanceof Criteria)
 >             {
 >                 Criteria pc = (Criteria) o;
 >                 flatten(pc, acc);
 >             }
 >             else
 >             {
 >              // null criteria doesn't have a binding variable.
 >              if (!(o instanceof ojb.broker.query.NullCriteria))
 >              {
 >                  SelectionCriteria c = (SelectionCriteria) o;
 >                  acc.add(c);
 >                 }
 >             }
 >         }
 >         return acc;
 >     }
 >
 > null doesn't have a binding variable, so we skip it. Are there other
 > criteria types that don't have a bind variable ($X).
 >
 > Thomas, could you commit this fix? I'm still getting my CVS access set up
 > (and figuring out cvs :))
 >
 >
 >
 >
 >

RE: [OJB-developers] build junit

[bram <br...@in...>]

Got the same here,

Think there is a bug in RepositoryPersistor



-----Original Message-----
From: obj...@li...
[mailto:obj...@li...] On Behalf
Of Oleg Nitz
Sent: 01 May, 2002 22:11
To: obj...@li...
Subject: [OJB-developers] build junit

Hi,

I am trying to run JUnit tests with Sun JDK 1.3.1 under Linux
and I'm getting the following exception

    [junit] java.io.WriteAbortedException: Writing aborted by exception;

java.io.NotSerializableException: java.lang.reflect.Field
    [junit]     at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:445)

....

    [junit]     at 
ojb.broker.metadata.RepositoryPersistor.serialize(RepositoryPersistor.ja
va:182)
    [junit]     at 
ojb.broker.metadata.RepositoryPersistor.readFromFile(RepositoryPersistor
.java:93)

Any ideas on what's wrong with my configuration?

Thanks,
 Oleg

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We
supply
the hardware. You get the recognition. Email Us:
ban...@so...
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

RE: [OJB-developers] build junit

[Matthew B. <ma...@so...>]

Hi Oleg,

Nothing wrong with your configuration, Thomas checked in a quick hack to
make startup faster that fails due to some objects not being
serializable.you can go into the RepositoryPersistor and comment out the
calls to serialize and deserialize to get it to work (although startup will
be slower depending on the number of mapped objects)

Cheers,
Matthew

-----Original Message-----
From: Oleg Nitz [mailto:on...@uk...] 
Sent: Wednesday, May 01, 2002 1:11 PM
To: obj...@li...
Subject: [OJB-developers] build junit

Hi,

I am trying to run JUnit tests with Sun JDK 1.3.1 under Linux
and I'm getting the following exception

    [junit] java.io.WriteAbortedException: Writing aborted by exception; 
java.io.NotSerializableException: java.lang.reflect.Field
    [junit]     at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:445)

....

    [junit]     at 
ojb.broker.metadata.RepositoryPersistor.serialize(RepositoryPersistor.java:1
82)
    [junit]     at 
ojb.broker.metadata.RepositoryPersistor.readFromFile(RepositoryPersistor.jav
a:93)

Any ideas on what's wrong with my configuration?

Thanks,
 Oleg

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] build junit

[Oleg N. <on...@uk...>]

Hi,

I am trying to run JUnit tests with Sun JDK 1.3.1 under Linux
and I'm getting the following exception

    [junit] java.io.WriteAbortedException: Writing aborted by exception; 
java.io.NotSerializableException: java.lang.reflect.Field
    [junit]     at 
java.io.ObjectInputStream.readObject(ObjectInputStream.java:445)

....

    [junit]     at 
ojb.broker.metadata.RepositoryPersistor.serialize(RepositoryPersistor.java:182)
    [junit]     at 
ojb.broker.metadata.RepositoryPersistor.readFromFile(RepositoryPersistor.java:93)

Any ideas on what's wrong with my configuration?

Thanks,
 Oleg

Re: [OJB-developers] OJB with Ms Access

[Thomas M. <tho...@ho...>]

Hi Sara

Sara Facchinetti wrote:

> Hi,
> 
> I tried to use ojb with Ms Access but something was wrong.
> 
> If I put on the repository.xml the tag <jdbc.level>1.0</jdbc.level> the
> application gives me the following error "[BOOT] ERROR: unknown literal:
> jdbc.level
> [ojb.broker.metadata.RepositoryXmlHandler] ERROR: null".


Mhh, that's strange. Does your repository.dtd have entries like:
<!ELEMENT JdbcConnectionDescriptor (dbms.name, jdbc.level?, 
((driver.name, url.protocol, url.subprotocol, url.dbalias) | 
datasource.name), user.name?, user.passwd?)>

and

<!ELEMENT jdbc.level (#PCDATA)>


If not, your DTD is corrupt. If yes, something must be wrong with your 
xml file.

Your JdbcConnectionDescriptor should look like this:

     <JdbcConnectionDescriptor id="default">
         <dbms.name>MsAccess</dbms.name>
         <jdbc.level>1.0</jdbc.level>
         <driver.name>sun.jdbc.odbc.JdbcOdbcDriver</driver.name>
         <url.protocol>jdbc</url.protocol>
         <url.subprotocol>odbc</url.subprotocol>
         <url.dbalias>OJB</url.dbalias>
     </JdbcConnectionDescriptor>

JDBC level 1.0 is required for proper working with access.

Currently there are some Junit tests that do not pass for access (BLOB 
and CLOB stuff) but most other things should work.

HTH,

Thomas


> 
> On the other hand, if I avoid to put the jdbc.level tag and I run the
> application when it tries to read from the db the error is
> "java.lang.NullPointerException
>         at
> sun.jdbc.odbc.JdbcOdbcPreparedStatement.clearParameter(JdbcOdbcPrepar
> edStatement.java:1026)
>         at
> sun.jdbc.odbc.JdbcOdbcPreparedStatement.setChar(JdbcOdbcPreparedState
> ment.java:2778)
>         at
> sun.jdbc.odbc.JdbcOdbcPreparedStatement.setString(JdbcOdbcPreparedSta
> tement.java:772)....."
> 
> Does someone know the solution?
> 
> Thanks
> sara
> 
> 
> 
> 
> 
> 

[OJB-developers] OJB with Ms Access

[Sara F. <sa...@li...>]

Hi,

I tried to use ojb with Ms Access but something was wrong.

If I put on the repository.xml the tag <jdbc.level>1.0</jdbc.level> the
application gives me the following error "[BOOT] ERROR: unknown literal:
jdbc.level
[ojb.broker.metadata.RepositoryXmlHandler] ERROR: null".

On the other hand, if I avoid to put the jdbc.level tag and I run the
application when it tries to read from the db the error is
"java.lang.NullPointerException
        at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.clearParameter(JdbcOdbcPrepar
edStatement.java:1026)
        at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.setChar(JdbcOdbcPreparedState
ment.java:2778)
        at
sun.jdbc.odbc.JdbcOdbcPreparedStatement.setString(JdbcOdbcPreparedSta
tement.java:772)....."

Does someone know the solution?

Thanks
sara

RE: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge ]

[Chris G. <CGr...@de...>]

For what it's worth, I'm for it.

C.

> -----Original Message-----
> From: Thomas Mahler [mailto:tho...@ho...]
> Sent: Wednesday, May 01, 2002 4:30 AM
> To: Bischof, Rainer
> Cc: ojb
> Subject: Re: [OJB-developers] [Fwd: [New Subproject Proposal]
> ObjectBridge ]
>=20
>=20
> Hi Rainer,
>=20
> thanks for your quick reply and your approval to change the=20
> license on=20
> you contributions!
>=20
> cheers,
> Thomas
>=20
> Bischof, Rainer wrote:
>=20
> > Sure, go for it. The reason is simple: Jakarta =3D> excellent=20
> reputation =3D>
> > more users & developers =3D> better code quality.=20
> > And that's what we always need! The bigger the user base=20
> the faster you
> > stabilize the code of new feature sets.
> >=20
> > The few bits I provided for OJB in the caching area are of=20
> course approved
> > for migration to the new license.
> >=20
> > Rainer
> >=20
> >=20
> > -----Original Message-----
> > From: Thomas Mahler [mailto:tho...@ho...]
> > Sent: Mittwoch, 1. Mai 2002 00:42
> > To: ojb
> > Subject: [OJB-developers] [Fwd: [New Subproject Proposal]=20
> ObjectBridge]
> >=20
> >=20
> > Hi all,
> >=20
> > I had been contacted by Jason van Zyl (from Jakarta Turbine project)
> > some time ago. He was looking for an opensource replacement=20
> for their
> > "homegrown" persistencelayer Torque.
> >=20
> > They made some tests and found OJB to be sufficient for their needs.
> > Jason was impressed by the flexibility and overall=20
> feature-set of OJB
> > and suggested that OJB should become an official jakarta project.
> >=20
> > I met Jason on monday and we had a discussions on the pros=20
> and cons of
> > becomimg a Jakarta project.
> >=20
> > we found several pros:
> > - Jakarta is a very well known OS initiative (even my boss=20
> has heared of
> > it ;-)). It has a great reputation to host first class opensource
> > software. being listed at jakarta would bring even more=20
> momentum behind ojb.
> > - we would attract more developers and contributors.
> > - the BSD style licence will it make more attractive to=20
> contibute back
> > to OJB
> > - users will have less headaches to choose a well reputed Jakarta
> > software than choosing some "insecure" and=20
> "never-heared-of-that-before"
> > stuff from the web.
> > - jakarta provides some support for marketing etc.
> >=20
> >=20
> > We did not find any cons, but we have to care for some details:
> > - Moving to Jakarta would require to change the license on=20
> all code to
> > the Apache license. All developers that have contributed to OJB must
> > consent on this. If someone does not want his or her stuff under the
> > Apache license we would have to rewrite those parts.
> > - there are some coding conventions (not very restrictive=20
> ones) required
> >    for jakarta projects.
> >=20
> >=20
> > I think that becoming a toplevel jakarta subproject will be=20
> a very good
> > thing for OJB in the long run. So I'm definitely voting to=20
> do this step.
> >=20
> > What do you think? Any objections? Do you see any problems wrt. to
> > licensing or something else?
> >=20
> > below you'll find Jason's proposal to the Jakarta project committee.
> >=20
> > cheers,
> >=20
> > Thomas
> >=20
> > ---
> > -------- Original Message --------
> > Subject: [New Subproject Proposal] ObjectBridge
> > Date: 29 Apr 2002 07:27:46 -0400
> > From: Jason van Zyl <jv...@ze...>
> > To: tho...@ho...
> >=20
> > Thomas, this is the message I would like to send to the=20
> Jakarta list.
> > Please feel free to make any changes you wish and when you are happy
> > with this I will send it to the general jakarta mailing list.
> >=20
> > <a href=3D"mailto:gen...@ja...">Jakarta
> > General</a>
> >=20
> > ---
> >=20
> > Hi,
> >=20
> > I would like to propose ObjectBridge
> > (http://objectbridge.sourceforge.net/) as a top level subproject of
> > Jakarta.
> >=20
> > For those not familiar with ObjectBridge it is arguably one=20
> of the most
> > advanced persistence layers available, commercial or=20
> otherwise. It is
> > accompanied by an extensive, current documentation set=20
> which includes a
> > quick start guide, tutorials, a FAQ, design documentation=20
> describing how
> > certain features of OJB have been implemented, and=20
> deployment guides.
> >=20
> > The developer community is incredibly strong and currently=20
> consists of
> > 17 inviduals: three of whom are Jakarta committers, and one=20
> of the core
> > Castor developers. So the project has the numbers and has=20
> displayed some
> > collaboration with other projects. There are developers=20
> from the Torque
> > team (the simple table->object persistence tool within the turbine
> > subproject) too so there is obvious interest in OJB. The=20
> current list of
> > developers can be found here:
> >=20
> > http://sourceforge.net/project/memberlist.php?group_id=3D13647
> >=20
> > I would also like to note that David Taylor, a Jetspeed fellow, also
> > contributed to the internal transaction mechanism. So again, another
> > point of interest within Jakarta.
> >=20
> > OJB is currently being used in the Jetspeed project, and=20
> integration is
> > well underway in the Turbine project and Thomas Mahler, the=20
> author of
> > OJB, uses OJB in conjunction with Struts as part of some of the
> > solutions his company provides for clients. Thomas is also a user of
> > TopLink, which is the only product that is even remotely=20
> comparable with
> > OJB, so he is very familiar with both and reports that OJB is on par
> > with TopLink with to respect to performance and available features.
> >=20
> > I won't go into a complete list of features, but here are=20
> some of the
> > features that set OJB apart:
> >=20
> > o Pluggable APIs: Currently there is the native=20
> PersistenceBroker API, a
> > full ODMG API (which provides enhanced transaction=20
> isolation) and a JDO
> > implementation is in the works. OJB has been designed to=20
> allow different
> > front-end APIs for maximum flexibility. The ODMG API, for=20
> example, is a
> > small set of classes layered over top the core of OJB. The JDO
> > implementation will be very similiar in nature.
> >=20
> > o Pluggable query APIs: currently supported are a criteria based API
> > (AST based mechansism), OQL and SODA. But again they are=20
> pluggable, so
> > for example the query mechanism in Torque could easily be=20
> made to work
> > with OJB.
> >=20
> > These two features alone make OJB attractive as different=20
> APIs can be
> > made so that existing users of different systems can use OJB without
> > forcing clients to change code. Trying this with Torque is=20
> going to be
> > one of my first exercises to see how well this mechanism=20
> works. There
> > are many tools like Torque and OJB can be made to work with=20
> the APIs of
> > these projects so that greater collaboration can occur within OJB
> > itself. One can take a look at the source and design of OJB=20
> and quickly
> > determine that OJB stands in a class of its own, is very=20
> reliable, very
> > flexible and very performant.
> >=20
> > The greatest feature with respect to development is the extensive
> > regression testing features and the testbed. There are=20
> currently 130+
> > test cases and a regression test that compares the=20
> performance of OJB
> > with native JDBC calls.
> >=20
> > A full list of features can be found here:
> >=20
> > http://objectbridge.sourceforge.net/features.html
> >=20
> > Currently the license of OJB is LGPL but in discussion with=20
> Thomas he
> > feels that a BSD style license like Apache's is actually a=20
> better model
> > and has no problem with changing the license if the=20
> donation of OJB is
> > accepted by the Jakarta PMC.
> >=20
> > This is really a one-of-a-kind project, and is definitely one of the
> > cases where an OSS implementation is close, if not better than its
> > commercial counterpart. The developer community is keen,=20
> there are great
> > number of users and we think that OJB would be a fabulous=20
> addition to
> > the set of projects that are currently housed at Jakarta.
> >=20
> >=20
>=20
>=20
>=20
>=20

Re: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge ]

[Thomas M. <tho...@ho...>]

Hi Rainer,

thanks for your quick reply and your approval to change the license on 
you contributions!

cheers,
Thomas

Bischof, Rainer wrote:

> Sure, go for it. The reason is simple: Jakarta => excellent reputation =>
> more users & developers => better code quality. 
> And that's what we always need! The bigger the user base the faster you
> stabilize the code of new feature sets.
> 
> The few bits I provided for OJB in the caching area are of course approved
> for migration to the new license.
> 
> Rainer
> 
> 
> -----Original Message-----
> From: Thomas Mahler [mailto:tho...@ho...]
> Sent: Mittwoch, 1. Mai 2002 00:42
> To: ojb
> Subject: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge]
> 
> 
> Hi all,
> 
> I had been contacted by Jason van Zyl (from Jakarta Turbine project)
> some time ago. He was looking for an opensource replacement for their
> "homegrown" persistencelayer Torque.
> 
> They made some tests and found OJB to be sufficient for their needs.
> Jason was impressed by the flexibility and overall feature-set of OJB
> and suggested that OJB should become an official jakarta project.
> 
> I met Jason on monday and we had a discussions on the pros and cons of
> becomimg a Jakarta project.
> 
> we found several pros:
> - Jakarta is a very well known OS initiative (even my boss has heared of
> it ;-)). It has a great reputation to host first class opensource
> software. being listed at jakarta would bring even more momentum behind ojb.
> - we would attract more developers and contributors.
> - the BSD style licence will it make more attractive to contibute back
> to OJB
> - users will have less headaches to choose a well reputed Jakarta
> software than choosing some "insecure" and "never-heared-of-that-before"
> stuff from the web.
> - jakarta provides some support for marketing etc.
> 
> 
> We did not find any cons, but we have to care for some details:
> - Moving to Jakarta would require to change the license on all code to
> the Apache license. All developers that have contributed to OJB must
> consent on this. If someone does not want his or her stuff under the
> Apache license we would have to rewrite those parts.
> - there are some coding conventions (not very restrictive ones) required
>    for jakarta projects.
> 
> 
> I think that becoming a toplevel jakarta subproject will be a very good
> thing for OJB in the long run. So I'm definitely voting to do this step.
> 
> What do you think? Any objections? Do you see any problems wrt. to
> licensing or something else?
> 
> below you'll find Jason's proposal to the Jakarta project committee.
> 
> cheers,
> 
> Thomas
> 
> ---
> -------- Original Message --------
> Subject: [New Subproject Proposal] ObjectBridge
> Date: 29 Apr 2002 07:27:46 -0400
> From: Jason van Zyl <jv...@ze...>
> To: tho...@ho...
> 
> Thomas, this is the message I would like to send to the Jakarta list.
> Please feel free to make any changes you wish and when you are happy
> with this I will send it to the general jakarta mailing list.
> 
> <a href="mailto:gen...@ja...">Jakarta
> General</a>
> 
> ---
> 
> Hi,
> 
> I would like to propose ObjectBridge
> (http://objectbridge.sourceforge.net/) as a top level subproject of
> Jakarta.
> 
> For those not familiar with ObjectBridge it is arguably one of the most
> advanced persistence layers available, commercial or otherwise. It is
> accompanied by an extensive, current documentation set which includes a
> quick start guide, tutorials, a FAQ, design documentation describing how
> certain features of OJB have been implemented, and deployment guides.
> 
> The developer community is incredibly strong and currently consists of
> 17 inviduals: three of whom are Jakarta committers, and one of the core
> Castor developers. So the project has the numbers and has displayed some
> collaboration with other projects. There are developers from the Torque
> team (the simple table->object persistence tool within the turbine
> subproject) too so there is obvious interest in OJB. The current list of
> developers can be found here:
> 
> http://sourceforge.net/project/memberlist.php?group_id=13647
> 
> I would also like to note that David Taylor, a Jetspeed fellow, also
> contributed to the internal transaction mechanism. So again, another
> point of interest within Jakarta.
> 
> OJB is currently being used in the Jetspeed project, and integration is
> well underway in the Turbine project and Thomas Mahler, the author of
> OJB, uses OJB in conjunction with Struts as part of some of the
> solutions his company provides for clients. Thomas is also a user of
> TopLink, which is the only product that is even remotely comparable with
> OJB, so he is very familiar with both and reports that OJB is on par
> with TopLink with to respect to performance and available features.
> 
> I won't go into a complete list of features, but here are some of the
> features that set OJB apart:
> 
> o Pluggable APIs: Currently there is the native PersistenceBroker API, a
> full ODMG API (which provides enhanced transaction isolation) and a JDO
> implementation is in the works. OJB has been designed to allow different
> front-end APIs for maximum flexibility. The ODMG API, for example, is a
> small set of classes layered over top the core of OJB. The JDO
> implementation will be very similiar in nature.
> 
> o Pluggable query APIs: currently supported are a criteria based API
> (AST based mechansism), OQL and SODA. But again they are pluggable, so
> for example the query mechanism in Torque could easily be made to work
> with OJB.
> 
> These two features alone make OJB attractive as different APIs can be
> made so that existing users of different systems can use OJB without
> forcing clients to change code. Trying this with Torque is going to be
> one of my first exercises to see how well this mechanism works. There
> are many tools like Torque and OJB can be made to work with the APIs of
> these projects so that greater collaboration can occur within OJB
> itself. One can take a look at the source and design of OJB and quickly
> determine that OJB stands in a class of its own, is very reliable, very
> flexible and very performant.
> 
> The greatest feature with respect to development is the extensive
> regression testing features and the testbed. There are currently 130+
> test cases and a regression test that compares the performance of OJB
> with native JDBC calls.
> 
> A full list of features can be found here:
> 
> http://objectbridge.sourceforge.net/features.html
> 
> Currently the license of OJB is LGPL but in discussion with Thomas he
> feels that a BSD style license like Apache's is actually a better model
> and has no problem with changing the license if the donation of OJB is
> accepted by the Jakarta PMC.
> 
> This is really a one-of-a-kind project, and is definitely one of the
> cases where an OSS implementation is close, if not better than its
> commercial counterpart. The developer community is keen, there are great
> number of users and we think that OJB would be a fabulous addition to
> the set of projects that are currently housed at Jakarta.
> 
> 

RE: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge ]

[Bischof, R. <rai...@ed...>]

Sure, go for it. The reason is simple: Jakarta => excellent reputation =>
more users & developers => better code quality. 
And that's what we always need! The bigger the user base the faster you
stabilize the code of new feature sets.

The few bits I provided for OJB in the caching area are of course approved
for migration to the new license.

Rainer


-----Original Message-----
From: Thomas Mahler [mailto:tho...@ho...]
Sent: Mittwoch, 1. Mai 2002 00:42
To: ojb
Subject: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge]


Hi all,

I had been contacted by Jason van Zyl (from Jakarta Turbine project)
some time ago. He was looking for an opensource replacement for their
"homegrown" persistencelayer Torque.

They made some tests and found OJB to be sufficient for their needs.
Jason was impressed by the flexibility and overall feature-set of OJB
and suggested that OJB should become an official jakarta project.

I met Jason on monday and we had a discussions on the pros and cons of
becomimg a Jakarta project.

we found several pros:
- Jakarta is a very well known OS initiative (even my boss has heared of
it ;-)). It has a great reputation to host first class opensource
software. being listed at jakarta would bring even more momentum behind ojb.
- we would attract more developers and contributors.
- the BSD style licence will it make more attractive to contibute back
to OJB
- users will have less headaches to choose a well reputed Jakarta
software than choosing some "insecure" and "never-heared-of-that-before"
stuff from the web.
- jakarta provides some support for marketing etc.


We did not find any cons, but we have to care for some details:
- Moving to Jakarta would require to change the license on all code to
the Apache license. All developers that have contributed to OJB must
consent on this. If someone does not want his or her stuff under the
Apache license we would have to rewrite those parts.
- there are some coding conventions (not very restrictive ones) required
   for jakarta projects.


I think that becoming a toplevel jakarta subproject will be a very good
thing for OJB in the long run. So I'm definitely voting to do this step.

What do you think? Any objections? Do you see any problems wrt. to
licensing or something else?

below you'll find Jason's proposal to the Jakarta project committee.

cheers,

Thomas

---
-------- Original Message --------
Subject: [New Subproject Proposal] ObjectBridge
Date: 29 Apr 2002 07:27:46 -0400
From: Jason van Zyl <jv...@ze...>
To: tho...@ho...

Thomas, this is the message I would like to send to the Jakarta list.
Please feel free to make any changes you wish and when you are happy
with this I will send it to the general jakarta mailing list.

<a href="mailto:gen...@ja...">Jakarta
General</a>

---

Hi,

I would like to propose ObjectBridge
(http://objectbridge.sourceforge.net/) as a top level subproject of
Jakarta.

For those not familiar with ObjectBridge it is arguably one of the most
advanced persistence layers available, commercial or otherwise. It is
accompanied by an extensive, current documentation set which includes a
quick start guide, tutorials, a FAQ, design documentation describing how
certain features of OJB have been implemented, and deployment guides.

The developer community is incredibly strong and currently consists of
17 inviduals: three of whom are Jakarta committers, and one of the core
Castor developers. So the project has the numbers and has displayed some
collaboration with other projects. There are developers from the Torque
team (the simple table->object persistence tool within the turbine
subproject) too so there is obvious interest in OJB. The current list of
developers can be found here:

http://sourceforge.net/project/memberlist.php?group_id=13647

I would also like to note that David Taylor, a Jetspeed fellow, also
contributed to the internal transaction mechanism. So again, another
point of interest within Jakarta.

OJB is currently being used in the Jetspeed project, and integration is
well underway in the Turbine project and Thomas Mahler, the author of
OJB, uses OJB in conjunction with Struts as part of some of the
solutions his company provides for clients. Thomas is also a user of
TopLink, which is the only product that is even remotely comparable with
OJB, so he is very familiar with both and reports that OJB is on par
with TopLink with to respect to performance and available features.

I won't go into a complete list of features, but here are some of the
features that set OJB apart:

o Pluggable APIs: Currently there is the native PersistenceBroker API, a
full ODMG API (which provides enhanced transaction isolation) and a JDO
implementation is in the works. OJB has been designed to allow different
front-end APIs for maximum flexibility. The ODMG API, for example, is a
small set of classes layered over top the core of OJB. The JDO
implementation will be very similiar in nature.

o Pluggable query APIs: currently supported are a criteria based API
(AST based mechansism), OQL and SODA. But again they are pluggable, so
for example the query mechanism in Torque could easily be made to work
with OJB.

These two features alone make OJB attractive as different APIs can be
made so that existing users of different systems can use OJB without
forcing clients to change code. Trying this with Torque is going to be
one of my first exercises to see how well this mechanism works. There
are many tools like Torque and OJB can be made to work with the APIs of
these projects so that greater collaboration can occur within OJB
itself. One can take a look at the source and design of OJB and quickly
determine that OJB stands in a class of its own, is very reliable, very
flexible and very performant.

The greatest feature with respect to development is the extensive
regression testing features and the testbed. There are currently 130+
test cases and a regression test that compares the performance of OJB
with native JDBC calls.

A full list of features can be found here:

http://objectbridge.sourceforge.net/features.html

Currently the license of OJB is LGPL but in discussion with Thomas he
feels that a BSD style license like Apache's is actually a better model
and has no problem with changing the license if the donation of OJB is
accepted by the Jakarta PMC.

This is really a one-of-a-kind project, and is definitely one of the
cases where an OSS implementation is close, if not better than its
commercial counterpart. The developer community is keen, there are great
number of users and we think that OJB would be a fabulous addition to
the set of projects that are currently housed at Jakarta.

-- 
jvz.

Jason van Zyl
jv...@ap...

http://tambora.zenplex.org








_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us:
ban...@so..._______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge]

[Jakob B. <jbr...@ho...>]

hi,

i vote for becoming a jakarta project.

jakob

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "ojb" <obj...@li...>
Sent: Wednesday, May 01, 2002 12:42 AM
Subject: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge]


> Hi all,
>
> I had been contacted by Jason van Zyl (from Jakarta Turbine project)
> some time ago. He was looking for an opensource replacement for their
> "homegrown" persistencelayer Torque.
>
> They made some tests and found OJB to be sufficient for their needs.
> Jason was impressed by the flexibility and overall feature-set of OJB
> and suggested that OJB should become an official jakarta project.
>
> I met Jason on monday and we had a discussions on the pros and cons of
> becomimg a Jakarta project.
>
> we found several pros:
> - Jakarta is a very well known OS initiative (even my boss has heared of
> it ;-)). It has a great reputation to host first class opensource
> software. being listed at jakarta would bring even more momentum behind
ojb.
> - we would attract more developers and contributors.
> - the BSD style licence will it make more attractive to contibute back
> to OJB
> - users will have less headaches to choose a well reputed Jakarta
> software than choosing some "insecure" and "never-heared-of-that-before"
> stuff from the web.
> - jakarta provides some support for marketing etc.
>
>
> We did not find any cons, but we have to care for some details:
> - Moving to Jakarta would require to change the license on all code to
> the Apache license. All developers that have contributed to OJB must
> consent on this. If someone does not want his or her stuff under the
> Apache license we would have to rewrite those parts.
> - there are some coding conventions (not very restrictive ones) required
>    for jakarta projects.
>
>
> I think that becoming a toplevel jakarta subproject will be a very good
> thing for OJB in the long run. So I'm definitely voting to do this step.
>
> What do you think? Any objections? Do you see any problems wrt. to
> licensing or something else?
>
> below you'll find Jason's proposal to the Jakarta project committee.
>
> cheers,
>
> Thomas
>
> ---
> -------- Original Message --------
> Subject: [New Subproject Proposal] ObjectBridge
> Date: 29 Apr 2002 07:27:46 -0400
> From: Jason van Zyl <jv...@ze...>
> To: tho...@ho...
>
> Thomas, this is the message I would like to send to the Jakarta list.
> Please feel free to make any changes you wish and when you are happy
> with this I will send it to the general jakarta mailing list.
>
> <a href="mailto:gen...@ja...">Jakarta
> General</a>
>
> ---
>
> Hi,
>
> I would like to propose ObjectBridge
> (http://objectbridge.sourceforge.net/) as a top level subproject of
> Jakarta.
>
> For those not familiar with ObjectBridge it is arguably one of the most
> advanced persistence layers available, commercial or otherwise. It is
> accompanied by an extensive, current documentation set which includes a
> quick start guide, tutorials, a FAQ, design documentation describing how
> certain features of OJB have been implemented, and deployment guides.
>
> The developer community is incredibly strong and currently consists of
> 17 inviduals: three of whom are Jakarta committers, and one of the core
> Castor developers. So the project has the numbers and has displayed some
> collaboration with other projects. There are developers from the Torque
> team (the simple table->object persistence tool within the turbine
> subproject) too so there is obvious interest in OJB. The current list of
> developers can be found here:
>
> http://sourceforge.net/project/memberlist.php?group_id=13647
>
> I would also like to note that David Taylor, a Jetspeed fellow, also
> contributed to the internal transaction mechanism. So again, another
> point of interest within Jakarta.
>
> OJB is currently being used in the Jetspeed project, and integration is
> well underway in the Turbine project and Thomas Mahler, the author of
> OJB, uses OJB in conjunction with Struts as part of some of the
> solutions his company provides for clients. Thomas is also a user of
> TopLink, which is the only product that is even remotely comparable with
> OJB, so he is very familiar with both and reports that OJB is on par
> with TopLink with to respect to performance and available features.
>
> I won't go into a complete list of features, but here are some of the
> features that set OJB apart:
>
> o Pluggable APIs: Currently there is the native PersistenceBroker API, a
> full ODMG API (which provides enhanced transaction isolation) and a JDO
> implementation is in the works. OJB has been designed to allow different
> front-end APIs for maximum flexibility. The ODMG API, for example, is a
> small set of classes layered over top the core of OJB. The JDO
> implementation will be very similiar in nature.
>
> o Pluggable query APIs: currently supported are a criteria based API
> (AST based mechansism), OQL and SODA. But again they are pluggable, so
> for example the query mechanism in Torque could easily be made to work
> with OJB.
>
> These two features alone make OJB attractive as different APIs can be
> made so that existing users of different systems can use OJB without
> forcing clients to change code. Trying this with Torque is going to be
> one of my first exercises to see how well this mechanism works. There
> are many tools like Torque and OJB can be made to work with the APIs of
> these projects so that greater collaboration can occur within OJB
> itself. One can take a look at the source and design of OJB and quickly
> determine that OJB stands in a class of its own, is very reliable, very
> flexible and very performant.
>
> The greatest feature with respect to development is the extensive
> regression testing features and the testbed. There are currently 130+
> test cases and a regression test that compares the performance of OJB
> with native JDBC calls.
>
> A full list of features can be found here:
>
> http://objectbridge.sourceforge.net/features.html
>
> Currently the license of OJB is LGPL but in discussion with Thomas he
> feels that a BSD style license like Apache's is actually a better model
> and has no problem with changing the license if the donation of OJB is
> accepted by the Jakarta PMC.
>
> This is really a one-of-a-kind project, and is definitely one of the
> cases where an OSS implementation is close, if not better than its
> commercial counterpart. The developer community is keen, there are great
> number of users and we think that OJB would be a fabulous addition to
> the set of projects that are currently housed at Jakarta.
>
> --
> jvz.
>
> Jason van Zyl
> jv...@ap...
>
> http://tambora.zenplex.org
>
>
>
>
>
>
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us:
ban...@so..._______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge]

[Jon B. <jon...@ac...>]

I say do it (not that I'm an active OJB developer, so what do I know ?
:-) )

We use an awful lot of Jakarta stuff in the work I do, which includes
the back end management system for a major credit card issuer.  The
stuff is definitely prime time enterprise quality and the reputation
amongst professinal J2EE developers is very high.

At the very least every OJB developer should be proud that the Jakarta
team rates you all so much.

Jon

On Tue, 2002-04-30 at 23:42, Thomas Mahler wrote:
> Hi all,
> 
> I had been contacted by Jason van Zyl (from Jakarta Turbine project)
> some time ago. He was looking for an opensource replacement for their
> "homegrown" persistencelayer Torque.
> 
> They made some tests and found OJB to be sufficient for their needs.
> Jason was impressed by the flexibility and overall feature-set of OJB
> and suggested that OJB should become an official jakarta project.
> 
> I met Jason on monday and we had a discussions on the pros and cons of
> becomimg a Jakarta project.
> 
> we found several pros:
> - Jakarta is a very well known OS initiative (even my boss has heared of
> it ;-)). It has a great reputation to host first class opensource
> software. being listed at jakarta would bring even more momentum behind ojb.
> - we would attract more developers and contributors.
> - the BSD style licence will it make more attractive to contibute back
> to OJB
> - users will have less headaches to choose a well reputed Jakarta
> software than choosing some "insecure" and "never-heared-of-that-before"
> stuff from the web.
> - jakarta provides some support for marketing etc.
> 
> 
> We did not find any cons, but we have to care for some details:
> - Moving to Jakarta would require to change the license on all code to
> the Apache license. All developers that have contributed to OJB must
> consent on this. If someone does not want his or her stuff under the
> Apache license we would have to rewrite those parts.
> - there are some coding conventions (not very restrictive ones) required
>    for jakarta projects.
> 
> 
> I think that becoming a toplevel jakarta subproject will be a very good
> thing for OJB in the long run. So I'm definitely voting to do this step.
> 
> What do you think? Any objections? Do you see any problems wrt. to
> licensing or something else?
> 
> below you'll find Jason's proposal to the Jakarta project committee.
> 
> cheers,
> 
> Thomas
> 
> ---
> -------- Original Message --------
> Subject: [New Subproject Proposal] ObjectBridge
> Date: 29 Apr 2002 07:27:46 -0400
> From: Jason van Zyl <jv...@ze...>
> To: tho...@ho...
> 
> Thomas, this is the message I would like to send to the Jakarta list.
> Please feel free to make any changes you wish and when you are happy
> with this I will send it to the general jakarta mailing list.
> 
> <a href="mailto:gen...@ja...">Jakarta
> General</a>
> 
> ---
> 
> Hi,
> 
> I would like to propose ObjectBridge
> (http://objectbridge.sourceforge.net/) as a top level subproject of
> Jakarta.
> 
> For those not familiar with ObjectBridge it is arguably one of the most
> advanced persistence layers available, commercial or otherwise. It is
> accompanied by an extensive, current documentation set which includes a
> quick start guide, tutorials, a FAQ, design documentation describing how
> certain features of OJB have been implemented, and deployment guides.
> 
> The developer community is incredibly strong and currently consists of
> 17 inviduals: three of whom are Jakarta committers, and one of the core
> Castor developers. So the project has the numbers and has displayed some
> collaboration with other projects. There are developers from the Torque
> team (the simple table->object persistence tool within the turbine
> subproject) too so there is obvious interest in OJB. The current list of
> developers can be found here:
> 
> http://sourceforge.net/project/memberlist.php?group_id=13647
> 
> I would also like to note that David Taylor, a Jetspeed fellow, also
> contributed to the internal transaction mechanism. So again, another
> point of interest within Jakarta.
> 
> OJB is currently being used in the Jetspeed project, and integration is
> well underway in the Turbine project and Thomas Mahler, the author of
> OJB, uses OJB in conjunction with Struts as part of some of the
> solutions his company provides for clients. Thomas is also a user of
> TopLink, which is the only product that is even remotely comparable with
> OJB, so he is very familiar with both and reports that OJB is on par
> with TopLink with to respect to performance and available features.
> 
> I won't go into a complete list of features, but here are some of the
> features that set OJB apart:
> 
> o Pluggable APIs: Currently there is the native PersistenceBroker API, a
> full ODMG API (which provides enhanced transaction isolation) and a JDO
> implementation is in the works. OJB has been designed to allow different
> front-end APIs for maximum flexibility. The ODMG API, for example, is a
> small set of classes layered over top the core of OJB. The JDO
> implementation will be very similiar in nature.
> 
> o Pluggable query APIs: currently supported are a criteria based API
> (AST based mechansism), OQL and SODA. But again they are pluggable, so
> for example the query mechanism in Torque could easily be made to work
> with OJB.
> 
> These two features alone make OJB attractive as different APIs can be
> made so that existing users of different systems can use OJB without
> forcing clients to change code. Trying this with Torque is going to be
> one of my first exercises to see how well this mechanism works. There
> are many tools like Torque and OJB can be made to work with the APIs of
> these projects so that greater collaboration can occur within OJB
> itself. One can take a look at the source and design of OJB and quickly
> determine that OJB stands in a class of its own, is very reliable, very
> flexible and very performant.
> 
> The greatest feature with respect to development is the extensive
> regression testing features and the testbed. There are currently 130+
> test cases and a regression test that compares the performance of OJB
> with native JDBC calls.
> 
> A full list of features can be found here:
> 
> http://objectbridge.sourceforge.net/features.html
> 
> Currently the license of OJB is LGPL but in discussion with Thomas he
> feels that a BSD style license like Apache's is actually a better model
> and has no problem with changing the license if the donation of OJB is
> accepted by the Jakarta PMC.
> 
> This is really a one-of-a-kind project, and is definitely one of the
> cases where an OSS implementation is close, if not better than its
> commercial counterpart. The developer community is keen, there are great
> number of users and we think that OJB would be a fabulous addition to
> the set of projects that are currently housed at Jakarta.
> 
> -- 
> jvz.
> 
> Jason van Zyl
> jv...@ap...
> 
> http://tambora.zenplex.org
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so..._______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] Bug in OQLQueryImpl

[Jakob B. <jbr...@ho...>]

hi matthew,

EqualToColumnCriteria and SqlCriteria do not have bind variables,
BetweenCriteria has two of them.

jakob

----- Original Message -----
From: "Matthew Baird" <ma...@so...>
To: <obj...@li...>
Sent: Wednesday, May 01, 2002 7:36 AM
Subject: [OJB-developers] Bug in OQLQueryImpl


>
> During the criteria flattening, to create the bind iterator, all criteria,
> regardless of if they have actual bindable criteria or not, are added to
the
> bind iterator. I spent some time trying to find a rather nasty bug where
my
> criteria wasn't getting bound correctly and came up with this:
>
>
>     private Vector flatten(Criteria crit, Vector acc)
>     {
>         Enumeration e = crit.getElements();
>         while (e.hasMoreElements())
>         {
>             Object o = e.nextElement();
>             if (o instanceof Criteria)
>             {
>                 Criteria pc = (Criteria) o;
>                 flatten(pc, acc);
>             }
>             else
>             {
>              // null criteria doesn't have a binding variable.
>              if (!(o instanceof ojb.broker.query.NullCriteria))
>              {
>                  SelectionCriteria c = (SelectionCriteria) o;
>                  acc.add(c);
>                 }
>             }
>         }
>         return acc;
>     }
>
> null doesn't have a binding variable, so we skip it. Are there other
> criteria types that don't have a bind variable ($X).
>
> Thomas, could you commit this fix? I'm still getting my CVS access set up
> (and figuring out cvs :))
>
>

RE: [OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge ]

[Charles A. <cha...@hp...>]

Becoming a jakarta project Is Good News.

If voting is required, and if my vote means anything at all, +1 from me.

Cheers,

Charles.


This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.

[OJB-developers] Bug in OQLQueryImpl

[Matthew B. <ma...@so...>]

During the criteria flattening, to create the bind iterator, all criteria,
regardless of if they have actual bindable criteria or not, are added to the
bind iterator. I spent some time trying to find a rather nasty bug where my
criteria wasn't getting bound correctly and came up with this:


    private Vector flatten(Criteria crit, Vector acc)
    {
        Enumeration e = crit.getElements();
        while (e.hasMoreElements())
        {
            Object o = e.nextElement();
            if (o instanceof Criteria)
            {
                Criteria pc = (Criteria) o;
                flatten(pc, acc);
            }
            else
            {
             // null criteria doesn't have a binding variable.
             if (!(o instanceof ojb.broker.query.NullCriteria))
             {
                 SelectionCriteria c = (SelectionCriteria) o;
                 acc.add(c);
                }
            }
        }
        return acc;
    }

null doesn't have a binding variable, so we skip it. Are there other
criteria types that don't have a bind variable ($X).

Thomas, could you commit this fix? I'm still getting my CVS access set up
(and figuring out cvs :))

Re: [OJB-developers] Serialized Repository

[Thomas M. <tho...@ho...>]

Hi Jakob,


Jakob Braeuchi wrote:

 > hi,
 >
 > i have a strange problem with serialized repository:
 > the method testRowReader() fails. when i delete the serialized repository
 > and rerun the test it works ?


that's my fault, I checked in this repository serialization stuff
without proper testing :-(

I hope to get it fixed asap.

cheers,

Thomas

 >
 > jakob
 >
 > .[BOOT] INFO: OJB.properties:
 > 
file:/D:/Java/eclipse_0425/workspace/ojb-1-0/src/test/test/ojb/OJB.propertie
 > s
 > [BOOT] INFO: loading serialized repository
 > 
D:\Java\eclipse_0425\workspace\ojb-1-0\src\test\test\ojb\repository.xml.seri
 > alized
 > ....F....................................
 > .....
 > Time: 5.268
 > There was 1 failure:
 > 1)
 > 
testRowReader(test.ojb.broker.PersistenceBrokerTest)junit.framework.Assertio
 > nFailedError: detail should be loaded by RowReader !
 > at
 > 
test.ojb.broker.PersistenceBrokerTest.testRowReader(PersistenceBrokerTest.ja
 > va:803)
 > at test.ojb.broker.AllTests.main(AllTests.java:25)
 > FAILURES!!!
 > Tests run: 46, Failures: 1, Errors: 0
 >
 >
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >
 >
 >
 >

[OJB-developers] [Fwd: [New Subproject Proposal] ObjectBridge]

[Thomas M. <tho...@ho...>]

Hi all,

I had been contacted by Jason van Zyl (from Jakarta Turbine project)
some time ago. He was looking for an opensource replacement for their
"homegrown" persistencelayer Torque.

They made some tests and found OJB to be sufficient for their needs.
Jason was impressed by the flexibility and overall feature-set of OJB
and suggested that OJB should become an official jakarta project.

I met Jason on monday and we had a discussions on the pros and cons of
becomimg a Jakarta project.

we found several pros:
- Jakarta is a very well known OS initiative (even my boss has heared of
it ;-)). It has a great reputation to host first class opensource
software. being listed at jakarta would bring even more momentum behind ojb.
- we would attract more developers and contributors.
- the BSD style licence will it make more attractive to contibute back
to OJB
- users will have less headaches to choose a well reputed Jakarta
software than choosing some "insecure" and "never-heared-of-that-before"
stuff from the web.
- jakarta provides some support for marketing etc.


We did not find any cons, but we have to care for some details:
- Moving to Jakarta would require to change the license on all code to
the Apache license. All developers that have contributed to OJB must
consent on this. If someone does not want his or her stuff under the
Apache license we would have to rewrite those parts.
- there are some coding conventions (not very restrictive ones) required
   for jakarta projects.


I think that becoming a toplevel jakarta subproject will be a very good
thing for OJB in the long run. So I'm definitely voting to do this step.

What do you think? Any objections? Do you see any problems wrt. to
licensing or something else?

below you'll find Jason's proposal to the Jakarta project committee.

cheers,

Thomas

---
-------- Original Message --------
Subject: [New Subproject Proposal] ObjectBridge
Date: 29 Apr 2002 07:27:46 -0400
From: Jason van Zyl <jv...@ze...>
To: tho...@ho...

Thomas, this is the message I would like to send to the Jakarta list.
Please feel free to make any changes you wish and when you are happy
with this I will send it to the general jakarta mailing list.

<a href="mailto:gen...@ja...">Jakarta
General</a>

---

Hi,

I would like to propose ObjectBridge
(http://objectbridge.sourceforge.net/) as a top level subproject of
Jakarta.

For those not familiar with ObjectBridge it is arguably one of the most
advanced persistence layers available, commercial or otherwise. It is
accompanied by an extensive, current documentation set which includes a
quick start guide, tutorials, a FAQ, design documentation describing how
certain features of OJB have been implemented, and deployment guides.

The developer community is incredibly strong and currently consists of
17 inviduals: three of whom are Jakarta committers, and one of the core
Castor developers. So the project has the numbers and has displayed some
collaboration with other projects. There are developers from the Torque
team (the simple table->object persistence tool within the turbine
subproject) too so there is obvious interest in OJB. The current list of
developers can be found here:

http://sourceforge.net/project/memberlist.php?group_id=13647

I would also like to note that David Taylor, a Jetspeed fellow, also
contributed to the internal transaction mechanism. So again, another
point of interest within Jakarta.

OJB is currently being used in the Jetspeed project, and integration is
well underway in the Turbine project and Thomas Mahler, the author of
OJB, uses OJB in conjunction with Struts as part of some of the
solutions his company provides for clients. Thomas is also a user of
TopLink, which is the only product that is even remotely comparable with
OJB, so he is very familiar with both and reports that OJB is on par
with TopLink with to respect to performance and available features.

I won't go into a complete list of features, but here are some of the
features that set OJB apart:

o Pluggable APIs: Currently there is the native PersistenceBroker API, a
full ODMG API (which provides enhanced transaction isolation) and a JDO
implementation is in the works. OJB has been designed to allow different
front-end APIs for maximum flexibility. The ODMG API, for example, is a
small set of classes layered over top the core of OJB. The JDO
implementation will be very similiar in nature.

o Pluggable query APIs: currently supported are a criteria based API
(AST based mechansism), OQL and SODA. But again they are pluggable, so
for example the query mechanism in Torque could easily be made to work
with OJB.

These two features alone make OJB attractive as different APIs can be
made so that existing users of different systems can use OJB without
forcing clients to change code. Trying this with Torque is going to be
one of my first exercises to see how well this mechanism works. There
are many tools like Torque and OJB can be made to work with the APIs of
these projects so that greater collaboration can occur within OJB
itself. One can take a look at the source and design of OJB and quickly
determine that OJB stands in a class of its own, is very reliable, very
flexible and very performant.

The greatest feature with respect to development is the extensive
regression testing features and the testbed. There are currently 130+
test cases and a regression test that compares the performance of OJB
with native JDBC calls.

A full list of features can be found here:

http://objectbridge.sourceforge.net/features.html

Currently the license of OJB is LGPL but in discussion with Thomas he
feels that a BSD style license like Apache's is actually a better model
and has no problem with changing the license if the donation of OJB is
accepted by the Jakarta PMC.

This is really a one-of-a-kind project, and is definitely one of the
cases where an OSS implementation is close, if not better than its
commercial counterpart. The developer community is keen, there are great
number of users and we think that OJB would be a fabulous addition to
the set of projects that are currently housed at Jakarta.

-- 
jvz.

Jason van Zyl
jv...@ap...

http://tambora.zenplex.org

[OJB-developers] Bug in PersistenceBrokerFactoryJ2EEImpl

[Matthew B. <ma...@so...>]

Summary: use in J2EE environment is broken due to improperly overridden
configure() call.



public class PersistenceBrokerFactoryJ2EEImpl
    extends PersistenceBrokerFactoryDefaultImpl

    /*
     * @see Configurable#configure(Configuration)
     */
    public void configure(Configuration config) throws
ConfigurationException
   {
    }

The PersistenceBrokerFactoryJ2EEImpl extends
PersistenceBrokerFactoryDefaultImpl and overrides
PersistenceBrokerFactoryDefaultImpl's configure call with a no-op. During
startup PersistenceBrokerFactoryJ2EEImpl calls into the base class to call
the following:
public PersistenceBroker createNewBrokerInstance()
	{
		try
		{
			PersistenceBroker instance = null;
			Class implementationClass =
configuration.getPersistenceBrokerClass();
			Class[] types = {DescriptorRepository.class};
			Object[] args =
					{repository};
			instance = (PersistenceBroker)
implementationClass.getConstructor(types).newInstance(args);
			return instance;
		}
		catch (Throwable t)
		{
			throw new PersistenceBrokerException(t);
		}
	}

a null pointer happens when trying to call getConstructor on
implementationClass which is set during the configure call (never called due
to no-op override).

Solution is easy, remove the configure call from
PersistenceBrokerFactoryJ2EEImpl and let the base class handle it.

Thomas, can you commit this?