> 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.
Class identity in Java is a combination of the class name AND its ClassLoader.
So, the libraries smarte.proxy.Proxy is actually different than the applications smarte.proxy.Proxy, as they don't share the same class loader even though they have the same name.
That should help you narrow it down.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=236117