name of JDBCPersistenceProductDerivation

[Marc Logemann <ml...@logemann.org>]

Hi,

like Kevin i am also crawling through the bootstrapping process which  
has its challenges because of all its JAR-Services API woodoo. So far  
i understand that OpenJPA looks for ProductDerivations in services/ 
org.apache.openjpa.conf.ProductDerivation file and will store all  
classnames it finds. Currently of course its only one, the JPA  
derived JDBCPersistenceProductDerivation. I assume that kodo users  
will soon get a distro with OpenJPA.jar + KodJDOaddon.jar that will  
also contain a META-INF/services/ 
org.apache.openjpa.conf.ProductDerivation file with a different  
implementation of ProductDerivation.

Now i wonder how good the name "JDBCPersistenceProductDerivation" is  
because it says nothing about the spec it uses. It clearly sets  
constants like PersistenceProductDerivation.SPEC_JPA. so its  
obviously JPA related ;-) Or do i miss something here? Since i dont  
know the JDO side of Kodo, i can only guess here.

One more: why is there no openjpa.xml? I saw that it can provide  
globals (constants?) while bootstrapping but i can find none in the  
source tree.

--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de

RE: name of JDBCPersistenceProductDerivation

[Patrick Linskey <pl...@bea.com>]

> > One more: why is there no openjpa.xml? I saw that it can provide  
> > globals (constants?) while bootstrapping but i can find 
> none in the  
> > source tree.
> 
> Because you can use the JPA-standard persistence.xml instead, which  
> is loaded by default whenever no explicit alternate is provided,  
> according to the JPA spec.  The JDO spec doesn't have a default  
> properties file location, so kodo.properties is somewhat useful  
> there, but we don't expect many users to want an openjpa.xml globals  
> file.

Meanwhile, we (BEA) are working on a XML configuration file format for
configuring Kodo in a WebLogic Server environment. Currently, we're
calling this file "persistence-configuration.xml"; the basic idea is
that all the non-JPA-standard information will be in
persistence-configuration.xml, and people will not need to use the
name-value pairs in the persistence.xml. We (BEA) would love to get this
format or something like it into OpenJPA -- I should send out an email
outlining what we've done so far one of these days.

-Patrick
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Re: name of JDBCPersistenceProductDerivation

[Abe White <aw...@bea.com>]

> Now i wonder how good the name "JDBCPersistenceProductDerivation"  
> is because it says nothing about the spec it uses

The package name of JPA is javax.persistence.  So any time there's a  
class/package in OpenJPA that has "persistence" in it, it's referring  
to JPA.  For the JDO equivalent in Kodo, replace "persistence" with  
"JDO".

We had to name these things while the spec was still called "EJB 3",  
so just be thankful we didn't wind up with "EJB" everywhere :)

> One more: why is there no openjpa.xml? I saw that it can provide  
> globals (constants?) while bootstrapping but i can find none in the  
> source tree.

Because you can use the JPA-standard persistence.xml instead, which  
is loaded by default whenever no explicit alternate is provided,  
according to the JPA spec.  The JDO spec doesn't have a default  
properties file location, so kodo.properties is somewhat useful  
there, but we don't expect many users to want an openjpa.xml globals  
file.
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.