Translatable ClassLoaders

[flavia.rainone]

Kabir,

Why does AspectManager enforces the class loader to be Translatable in order to use it for classpool creation (lines 770-778)?

public ClassPool findClassPool(ClassLoader cl)
 {
 if (!(cl instanceof Translatable))
 {
 // findClassPool has problems with boot and system classes.
 return registerClassLoader(SecurityActions.getContextClassLoader());
 }
 return registerClassLoader(cl);
 }

I can't find any reference to this interface (except for the one above), nor any references to the method this interface declares (getResourceLocally). I have searched trunk and the class pool classes in javassist.

This is causing problems for standalone users with multi-classloader environments:


http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160969#4160969

[flavia.rainone]

The commentary

// findClassPool has problems with boot and system classes.

does not mean too much to me, since it doesn't tell what type of problems we can get.

[kabirkhan]

Translatable is for integration with the UnifiedClassLoader in JBoss 4.x and with the RealClassLoader in JBoss 5. Basically, they will call AspectManager.transform() once a class is loaded. So basically Translatable means it is a JBoss AS classloader.

We haven't really done many tests with clever classloader stuff outside of JBoss, so I guess this is why we haven't picked this up before. I think the method shown should be this instead:

 public ClassPool findClassPool(ClassLoader cl)
 {
 if (!(cl instanceof Translatable))
 {
 // findClassPool has problems with boot and system classes.
 if (cl == null)
 {
 return registerClassLoader(SecurityActions.getContextClassLoader());
 }
 }
 return registerClassLoader(cl);
 }


For boot and system classes Class.getClassLoader() will return null, and I think that might be what the comment refers to?

[flavia.rainone]

Great! I'll try to fix it and see if no aop tests (standalone and AS) get broken with it:

http://jira.jboss.com/jira/browse/JBAOP-606