users@glassfish.java.net

Re: ClassLoading problem while migrating application from GF v2 to GF v3

From: Sanjeeb Sahoo <sahoo_at_sun.com>
Date: Mon, 28 Jun 2010 21:11:00 +0530

On Monday 28 June 2010 08:17 PM, glassfish_at_javadesktop.org wrote:
> Thank you very much for your answer.
>
> The first issue is resolved. Thank you one more time. I can explain why java mail was searching for CGLib. When I am creating a proxy for some class from JavaMail bundle, CGLib defines the proxy (calls classloader.define()) using classloader that was used for loading parent class. Since we are creating a proxy of a class from JavaMail bundle, classloader from this bundle will be used. The code generated by CGLib is using some utility classes from CGLib bundle, but the proxy is defined using the classLoader of a JavaMail bundle. In this case the proxy will search for the utility classes though classloader of a java mail bundle, which will never find them, since JavaMail does not import cglib. There is quite similar problem with hibernate that was trying to load entity classes using its classloader. Possible solution is to change the manifest of a mail bundle, which is not really good approach of course.
>
Can't CGLib be configured like java.lang.reflectProxy to use a different
class loader?
> I have also noticed that normal web applications are resolved before bundles from autodeploy/bundles folder. This means that if some web app is using exported class from some bundle, after the server restart this application will not be initialized at all because of the missing class. Is it possible to somehow configure order in which different applications are resolved?
>
>
This is not true. Bundles from autodeploy/bundles will get resolved if
any web application needs it. What makes you think they get resolved
only after the web app is initialized? Did you actually see this behavior?

Sahoo
> Thanks in advance,
> Michael
> [Message sent by forum member 'smikesh']
>
> http://forums.java.net/jive/thread.jspa?messageID=476133
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>