openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: how to disable toplink?
Date Mon, 27 Nov 2006 09:50:51 GMT
Hi Roger,

Sorry for the late reply; I'm traveling.

On Nov 22, 2006, at 9:41 PM, roger.keays wrote:

> Craig L Russell wrote:
>> The issue with this is in Persistence. The results of finding the
>> services the very first time is cached in a static variable. The only
>> way I can see to make this work is to use your own version of
>> Persistence that is also deployed in your WAR file. If you use the
>> Persistence.class that is shared in the server, you can never see the
>> provider in your WAR file. So you would have to use the non-
>> delegating WAR file loader along with your own copy of the
>> persistence.jar that contains Persistence.class.
> That was my original plan, but it seems that you can't actually do  
> this
> since, according to SRV2.4 #9.7.2:
> "servlet containers that are part of a J2EE product should not  
> allow the
> application to
> override J2SE or J2EE platform classes, such as those in java.* and  
> javax.*
> namespaces, that either J2SE or J2EE do not allow to be modified."
> So the container is right to load it's own Persistence.class  
> instead of
> yours,

As far as I've understood, the Servlet container is specifically  
exempted from the general requirement, so applications can load  
earlier versions (or specific versions) of platform classes. That's  
so an application can actually depend on the behavior of a version of  
e.g. JAXB that is no longer current.

> and the only correct way is to install the persistence provider into
> the container itself. Unless of course you just...
> PersistenceProvider provider = new
> org.apache.openjpa.persistence.PersistenceProviderImpl();
> EntityManagerFactory emf = provider.createEntityManagerFactory 
> ("default");
> :)
> (note, I'm not using dependency injection here)

This should work, but inappropriately binds your application to  
OpenJPA, which I thought you were trying to avoid. And this approach  
does not work at all if you want to use the container to inject  

So, IMHO we either have to have a new Persistence.class loaded by the  
servlet container; OR we have a bug in the Persistence implementation.

It might be a good idea at this time to raise this issue on the alias and see if the  
implementation team has any comments. You can also send comments to for expert group responses in case the  
current spec is inadequate to resolve this issue.

>> If you use the server's JNDI lookup, or put the OpenJPA jar file into
>> the server's shared library, you should be able to avoid this issue.
>> Craig
>> On Nov 22, 2006, at 10:58 AM, Patrick Linskey wrote:
>>> My read of the spec is that while this deployment isn't explicitly
>>> called out, it certainly is strongly implied, and at the very  
>>> least an
>>> appserver should provide clear instructions for how to deploy  
>>> OpenJPA
>>> for use in such an environment.
>>> -Patrick
>>> -- 
>>> Patrick Linskey
>>> BEA Systems, Inc.
>>> ____________________________________________________________________ 
>>> __
>>> _
>>> 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.
>>>> -----Original Message-----
>>>> From: Marc Prud'hommeaux [] On
>>>> Behalf Of Marc Prud'hommeaux
>>>> Sent: Tuesday, November 21, 2006 11:25 PM
>>>> To:
>>>> Subject: Re: how to disable toplink?
>>>> Roger-
>>>> What happens if you put the OpenJPA jars and dependencies in the
>>>> system classpath of the container? Does it work then?
>>>> 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.p
>>>> ersisten
>>>>> 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: 
>>>>> disable-
>>>>> toplink--tf2683540.html#a7485258
>>>>> Sent from the open-jpa-dev mailing list archive at
>> Craig Russell
>> Architect, Sun Java Enterprise System 
>> jdo
>> 408 276-5638
>> P.S. A good JDO? O, Gasp!
> -- 
> View this message in context: 
> toplink--tf2683540.html#a7500820
> Sent from the open-jpa-dev mailing list archive at

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message