[jboss-user] [JBoss AOP Development] New message: "Re: ClassPool Refactoring"

Flavia Rainone do-not-reply at jboss.com
Tue Feb 2 07:07:29 EST 2010


User development,

A new message was posted in the thread "ClassPool Refactoring":

http://community.jboss.org/message/523640#523640

Author  : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com

Message:
--------------------------------------------------------------
After porting JBAOP-765, JBAOP-768 and JBAOP-763 to JBoss AOP branch 742, I still see a couple of failures, both related to subclassing tests.
 
It took me a while, but I finally discovered what is causing those failures. The problem is in the classpool structure. By some unexpected reason, the parent class pool of ExtClassLoader is a classpool representing a class loader that belongs to default domain. Since ExtClassLoader is parent of the parent of the default domain, that classpool is in the delegation chain of itself. It also belongs to the delegation chain of other classpools, which is clearly a bug.
 
This bug manifests itself only on corner cases, and it can be seen only by debugging Javassist. That's why it was so hard to find out. For example, one of the failures I was seeing, in AOPUnitTestCase, was happening because the access to POJO.protectedField below was not woven.
 
public class POJOChild extends POJO
{
 ...
 
 public void accessProtectedField()
   {
      protectedField += 1;
      System.out.println("protectedField = " + protectedField);
   }
}

 
JBoss AOP Transformer was doing everything correctly, but the javassist CodeConverter was failing to replace the accesses to protectedField above by calls to the wrapper methods of such joinpoints. I discovered that, once the CodeConverter found those accesses, it matched the name of the field correctly, but it failed to match the class that declares the protectedField, because it obtained a CtClass instance representing POJO that was not the same instance contained in the CodeConverter, even though both instances represented the same classes (one of the instances was retrieved from the correct class loader, the other one was not).
 
Now, I'll investigate to see why the classpool hierarchy is wrong, so I can find out how to fix it.

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/523640#523640




More information about the jboss-user mailing list