We are seeing an unexpected class loader behaviour in the remote clustering tests, which is resulting in a RuntimeException thrown by JBoss AOP, when aop is run in classical instrumentation mode. The cause of this exception is that JBoss AOP is trying to create a class that has already been created and loaded... JBoss AOP tries to create such a class because the class loader that defined the class is not able of loading the same class, which is totally unexpected. Look at the pseudocode below: ClassLoader myLoader = ....; | Class class = myLoader.defineClass(....); | System.out.println("Same class loader: " + (myLoader == class.getClassLoader())); | System.out.println("I wanted to use this loader: " + loader); | System.out.println("I got a class with this loader: " + loadedClass.getClassLoader()); | myLoader.load(class.getName()); | The call you can see at the second line is actually made by Javassist, through reflection... the code above is a simplification. The result of the code above, when run by JBoss AOP during class generation. is a ClassNotFoundException preceeded by the messages: | Same class loader: false | I wanted to use this loader: sun.misc.Launcher$AppClassLoader@1a5ab41 | I got a class with this loader: org.jboss.test.messaging.tools.container.ClassLoaderJMXWrapper@6fa9fc | Since the call defineClass has been made to sun.misc.Launcher$AppClassLoader@1a5ab41, we need this class to be able of loading the class later, instead of throwing a ClassNotFoundException. Does anybody know why we are seeing this behaviour? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142731#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...