Hi Marina,
See my comment in line...
Marina Vatkina wrote:
> Edson Carlos Ericksson Richter wrote:
>> Please, see comments inline...
>>
>>
>> Marina Vatkina escreveu:
>>
>>> In Glassfish each deployed app gets its own class loader, so each
>>> class loader loads its own provider class and as a result, each
>>> persistence.xml is processed completely separately.
>>
>> good, but I'm still having same problem on Glassfish... Maybe I need
>> a more recent version (I'm using V1U1)
>
> No, it should be the same. Persistence uses
> Thread.currentThread().getContextClassLoader() to load the provider
> class, which IMHO should be different for different applications in
> any version of GF. But I can be wrong.
>
What you said holds good for Java EE use of JPA, but this may not be
true for applications that use JPA in Java SE style in a container.
javax.persistence.Persistence caches all the providers in a static
variable, and that's the problem:
*protected static final Set<PersistenceProvider> providers = new
HashSet<PersistenceProvider>();*
Since Persistence.class is loaded by a class loader which is very high
in the delegation chain, once a provider class is loaded by any
application, it is always used by all other subsequent applications in
the container! This will explain the behavior seen by Edson Richter, right?
In fact, there is another side effect of this cache. Persistence.class
caches the set providers assuming the class loader space is static,
which is not true in a container environment.
This looks like a bug to me.
Thanks,
Sahoo