openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brady <>
Subject Re: how to disable toplink?
Date Wed, 22 Nov 2006 17:40:03 GMT
Just to note that we have both Toplink and OpenJPA deployed entirely 
inside a single EAR file under WebSphere 6.1.(which is Java 5 but J2EE 4).

We can switch it back and forth between Toplink and OpenJPA modes of 
operation, without regenerating the EAR, as follows.

 - change the provider name in persistence.xml.
 - leave both  toplink-essentials.jar and the openjpa jars in the root 
of the ear at all times
 - to run in openjpa mode, just update the provider name persistence.xml 
and in remove the dependency (manifest classpath entry) for 
 - it is not necessary to remove the dependencies on the openjpa jars 
when running under toplink.
 - it is not necessary to ever change any build paths or rebuild

 The reason that it is necessary to remove the dependency (classpath 
entry) for toplink when operating in openjpa mode is that otherwise 
toplink briefly gets control when openjpa enumerates the providers, and 
at that point toplink gets fatal exceptions because it is not the 
provider in persistence.xml.

 When running in toplink mode, toplink enumerates the openjpa provider 
but openjpa returns control nicely and does nothing when it sees that it 
has nothing to do!

 Incidentally, this is somewhat past tense for us because we have now 
switched to standard operation on OpenJPA and find it superior. So we 
may soon remove the toplink-essentials jar altogether.





Marc Prud'hommeaux wrote:
> Roger-
> I think the first step would be to get it working in glassfish when 
> deployed globally, and then move from there to seeing if it is 
> possible to deploy it within a WAR.
> What is the error you get (if any) if you deploy globally? The 
> following persistence.xml worked the last time I tried it:
> <persistence xmlns="" 
> version="1.0">
>     <persistence-unit name="pu1">
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>

>         <jta-data-source>jdbc/__default</jta-data-source>
>         <properties>
>             <property name="openjpa.Log" value="DefaultLevel=TRACE"/>
>             <property name="openjpa.jdbc.SynchronizeMappings" 
> value="buildSchema"/>
>         </properties>
>     </persistence-unit>
> </persistence>
> On Nov 22, 2006, at 2:57 AM, roger.keays wrote:
>> Hi Marc,
>> Marc Prud wrote:
>>> What happens if you put the OpenJPA jars and dependencies in the
>>> system classpath of the container? Does it work then?
>> I did try this unsuccessfully on glassfish, although some people have
>> reported that they can get this to work. I'm really looking for a 
>> solution
>> that doesn't require the user to hack their container though.
>> Roger
>>> If so, then that might be the only solution, currently. IIRC, the
>>> spec doesn't say anything about allowing JPA implementations
>>> themselves to be bundled into WARs or EARs, so there might no be any
>>> generic way to do so (which isn't to say that it's impossible; it
>>> might just require some container-specific glue to make it work).
>>> On Nov 21, 2006, at 11:59 PM, roger.keays wrote:
>>>> Is anybody aware of an effective way to ensure that the openjpa jars
>>>> distributed in a WAR are used for the persistence implementation? I
>>>> have
>>>> tried
>>>> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</
>>>> provider>
>>>> in persistence.xml, and
>>>> javax.persistence.spi.PersistenceProvider=org.apache.openjpa.persisten
>>>> ce.PersistenceProviderImpl
>>>> in the emf properties map but neither appear to work. This problem
>>>> occurs
>>>> when deploying to Glassfish, oc4j and (to a lesser extent) Resin
>>>> (resin
>>>> provides a buggy ejb30.jar). It seems to be a classloading problem,
>>>> because
>>>> these containers load the Persistence.class from their own lib
>>>> instead of
>>>> the webapp's. Since that class can't find openjpa, it just falls
>>>> back to
>>>> toplink. I had expected the webapp's classes to be loaded in
>>>> preference to
>>>> the containers though.
>>>> Any suggestions?
>>>> Roger
>>>> --View this message in context:
>>>> toplink--tf2683540.html#a7485258
>>>> Sent from the open-jpa-dev mailing list archive at
>> --View this message in context: 
>> Sent from the open-jpa-dev mailing list archive at

View raw message