glassfish_at_javadesktop.org wrote:
>> I think there are multiple class loaders coming into
>> play here. The
>> class loader of the class whose method is being
>> executed is loading its
>> own smarte.proxy.Proxy.class which is not same as
>> what is being loaded
>> by reflectedClass's class loader.
>>
>
> Yup, that's exactly what has to be happening here.
>
> A simple example would be if you had some library jar stored, say, in the actual domain (like domain1/lib) but you also have duplicate code bundled with the EAR/WAR file. It could be as simple as having the interfaces bundled with the application.
>
> What happens is that when the library code looks for a class, it can only see other libraries bundled at the same level. But the classes within the application can see their application classes as well as the library classes.
>
> When the classloader in the application goes looking for, say, smarte.proxy.Proxy, it pulls the one bundled with the application.
>
> But then the application calls the library code, and when it wants a smarte.proxy.Proxy, it pulls its local version, the libraries classloader can't even see classes in the application.
>
>
AFAIK, this explanation holds good iff class loader delegation is turned
off for a web application (by configuring in sun-web.xml) in GlassFish
or a bug in GlassFish. User has to come back with more data points,
like, exception stack, answers to questions I raised earlier, etc.
-- Sahoo