Marina Vatkina wrote:
> 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.
Sure. Could you provide me a stack-trace that shows failure of toplink classes
being found? What classloader do we use during table creation?
>
> 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?
Usually the APPCPATH environment variable is used to append other libraries used
by the application client to the appclient's classpath. If a user does not want
to set APPCPATH, I think the toplink jars needs to be bundled with the appclient.
Thanks
--Siva.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>