[jboss-dev-forums] [JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

[flavia.rainone@jboss.com]

"Ales" wrote : If the CP works properly on top of CL, it should not need such exclusion. 
I see your point. If the CP mimics the ClassLoader perfectly, it shouldn't have this problem. The problem here is that the CP doesn't mimic it perfectly.
For every classloader that is not a RealClassLoader, the JBossClDelegatingClassPoolFactory replaces a null parent by a default classPool:
if (parent == null)
  | {
  |    parent = ClassPool.getDefault();
  | }
  | return new NonDelegatingClassPool(cl, parent, repository, true);

For example, if we have a URLClassLoader as the parent of a domain, the JBossClDelegatingCPFactory will create a NonDelegatingclassPool using the piece of code above to represent the parent of the domain. And, since the URLClassLoader, in cases like this, has a null parent, the factory will set the default ClassPool as the parent of the NonDelegatingClassPool (the Default ClassPool is a classpool that contains the system classpath).

Because of such a non-null parent, the exclusion is not working for class pools. :-(

On the other hand, if we kept the parent classpool as null, and if this non delegating classpool is required to load, say, java.lang.String, it will return a CtClass created by the NonDelegatingClassPool itself. This results in duplicates. Another NonDelegatingClassPool willl create its own CtClass representing String.class and so on. I'm not sure what are the consequences of this.

Interestingly, this problem doesn't occur with primitives. Javassist has an array of CtPrimitiveTypes, a subclass of CtClass, representing each one of the primitive types. The same collection is used for all classpools and if you try to get the classpool that loaded the primitive type, you get a null classpool. That's what I would like to see with a CtClass representing a String, for example. But creating a CtClass array with all classes of the bootstrap classpath is cumbersome, to say the least.

This is what I'll do. I'll leave the parent as null in the case above, which will make the exclusion mechanism work. And I'll try to filter out classes belonging to java.* and com.sun.* packages. Every class name that matches those will have an universal CtClass created for it (following the same that is done for primitives in the ClassPool), associated with a null ClassPool. For obvious reasons, I'm not very fond of this approach, but I think it is worth a shot, since it is this or implementing exclusion for classpools. Plus, I think it is the closest we can get to the ClassLoader's behaviour.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269699#4269699

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269699