Here's a link to the explanation of application-specific class loading
in the docs:
http://docsview.sfbay/app/docs/doc/819-3672/6n5sj2sho?a=view
June
Sivakumar Thyagarajan wrote:
> > For testing purposes, i patch the toplink-essential.jar to add all
> my classes.
>
> If it is part of toplink-essentials.jar, since toplink-essentials.jar
> is loaded by the shared chain classloader and your entity class
> [com.gemalto.mmserver.ocp.model.impl.portal.PortalReleaseEntity] is
> loaded by the application classloader, you would need to explicitly
> use the application's classloader to load a class that refer's the
> entity class.
>
> If you executing as part of the application, using the thread context
> classloader while calling Class.forName should do the trick, otherwise
> I am afraid you would need to find the application classloader and use
> it. However I don't know if such a behavior is supported or what other
> issues you might face while implementing this. Someone from the
> persistence team [copied] could help with this query further.
>
> Thanks
> --Siva.
>
> glassfish_at_javadesktop.org wrote:
>
>> The signature is Class.forName(String). I do not specify any
>> classloader.
>> The ObjectInvalidationReceiver is effectively part of classes that i
>> add in the toplink.jar.
>> For testing purposes, i patch the toplink-essential.jar to add all my
>> classes.
>>
>> What can i do to ensure that the toplink package has the visibility
>> of entity classes defined in my deployed ear ?
>>
>> Franck.
>> [Message sent by forum member 'franck_mosse' (franck_mosse)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=240926
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>