Javassist pool implementation

[adrian.brock]

So in recent weeks we have two new areas that want to use
Javassist to access reflection information.

1) JBossRetro to get hold of annotations in JDK1.4
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=74785&start=30
2) Javassist implementation of ClassInfo
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77714

Both of these are prototypes, they use the default classpool so neither understands
classloaders properly.

I know AOP already has a specialized ClassPool.
What do we need to do to share this implementation?
We don't want three different classpools all repeating the same work. :-)

[kabirkhan]

I think it should be possible to pull it out somewhere.

If we are moving JBoss AOP to use the ClassInfo stuff internally, the container would be a good place to put it as far as AOP is concerned. Dunno about JBoss Retro though?

[kabirkhan]

As an aside, I see that JavassistTypeInfoFactoryImpl always loads up the java.lang.reflect.Class before creating the CtClass. I guess that is because this is a first cut?

If we are to migrate AOP to use this we need to make this work without using java.lang.reflect.Class for loadtime weaving to work (You probably already know this :-)

[adrian.brock]

As an aside, I see that JavassistTypeInfoFactoryImpl always loads up the java.lang.reflect.Class before creating the CtClass. I guess that is because this is a first cut?

If we are to migrate AOP to use this we need to make this work without using java.lang.reflect.Class for loadtime weaving to work (You probably already know this :-)

Yes. See TypeInfo.java

 /**
 * Get the class
 *
 * @deprecated I'm not sure this should be here?
 * @return the class
 */
 Class getType();

The class is there only because things like the java bean property editors
are currently based on the class. It is serving more as a cache for the class
because my current pool impl doesn't understand classloaders.

[adrian.brock]

After some false starts I've realised that the AOP class pool
doens't really understand classloader either.

But it doesn't really matter for AOP since it is told the classloader
when it "intercepts" defineClass()

I'll need to think about it some more.

It is not an easy problem to solve without knowing
the classloading structure.