Siva,
I've just ran a small experiment, when I moved toplink jars from <install>/lib
to domains/domain1/lib, didn't modify the classpath and restarted the appserver
(all in developer profile as life proves to be more complicated in a cluster).
I used the example from Java Persistence Example page ([1]), and it correctly
loaded all classes at runtime.
I observed the following (different) problems though:
1. Drop-and-create table at deploy failed because the toplink classes were not
visible to the GF processing code. As this feature is supported only for the
default provider, it shouldn't affect users relying on other providers, but we
might want to spend some time narrowing down the problem anyway.
2. Toplink jars were not available to the appclient container. What is the
difference between classpath in the server and the appclient in regards to the
default locations? Or is it documented somewhere (sorry, I didn't search for it)
what the user must do in regards to the appclient classpath?
thanks,
-marina
[1]
https://glassfish.dev.java.net/javaee5/persistence/persistence-example.html
Sivakumar Thyagarajan wrote:
> Hi
>
>> It looks like I added the jars incorrectly. I have corrected what I
>> did, but
>> didn't use your exact instructions because I was afraid I would cause
>> problems with the server classpath due to possibly overriding some of the
>> server's classes with unmatching versions.
>
>
> This is the right choice. Instead of polluting the AS classloader
> namespace, it makes sense to add the hibernate jars at the common
> classloader level.
>
>> Instead, I added the hibernate jars to the GF Common Classloader by
>> adding
>> the jars to the domain-dir/lib directory. As described in the
>> Classloaders
>> chapter of the GF Developer's Guide, the Common Classloader is a lower
>> priority classloader than the System classloader.
>
>
> However this does not seem to work, because the application classloader
> or the common classloader does not seem to be employed during class
> deserialization.
>
> The classloader used to load the hibernate entity manager seems to be an
> ASURLClassLoader, (the classloader used to construct the shared chain).
>
> I think this is because ObjectInputStream's readObject internally uses
> the ObjectInputStream.latestUserDefinedLoader() to load the class. The
> last non-null classloader in the execution stack would be the
> classloader that loaded the statefulsessioncontainer [ie the shared
> chain] and hence we have this issue.
>
> We might need to set the application classloader as the classloader to
> load the entity manager if we need to support usecases where the
> persistence provider is bundled with the app.
>
> I am not a persistence/SFSB expert and so would let Marina/Mahesh
> comment on this. Thanks.
>
> > Caused by: java.lang.ClassNotFoundException:
> org.hibernate.ejb.EntityManagerImpl
> > at
> com.sun.appserv.server.util.ASURLClassLoader.loadClass(ASURLClassLoader.java:129)
>
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> > at java.lang.Class.forName0(Native Method)
> > at java.lang.Class.forName(Class.java:247)
> > at
> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
> > at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
> > at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> > at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
> > at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> > at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> > at
> com.sun.ejb.containers.StatefulSessionContainer.repopulateEEMMapsInContext(StatefulSessionContainer.java:2133)
>
>
> Thanks
> --Siva.
>
> glassfish_at_javadesktop.org wrote:
>
>> It looks like I added the jars incorrectly. I have corrected what I
>> did, but didn't use your exact instructions because I was afraid I
>> would cause problems with the server classpath due to possibly
>> overriding some of the server's classes with unmatching versions.
>>
>> Instead, I added the hibernate jars to the GF Common Classloader by
>> adding the jars to the domain-dir/lib directory. As described in the
>> Classloaders chapter of the GF Developer's Guide, the Common
>> Classloader is a lower priority classloader than the System classloader.
>> Unfortunately, I'm still getting errors that appear related to this
>> problem. Following is a stack trace: (Notice the errors seem to come
>> spaced around 4-5 minutes apart)
>>
>> Creating ProductSearchBean|#]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>