[stalep]

while waiting for the classloader changes i wish to push the work ive done to jboss-reflect/trunk. it uses the same classloader strategy thats in trunk now so it wont change anything.
ive already created a factory/interface to fetch the classpool which can easily be replaced when kabir is done.
ill look over the tests and probably extend a few a bit more, then ill try to write up some docs on the wiki on how it works and hopefully merge next week if noone objects.

[stalep]

i commited the changes to trunk today. the interfaces for the expression editor are in, but the implementation isnt done. ill wait with that untill we get confirmation that aop will be refactored to use jboss-reflect.

the documentation site havent been added yet, ive contacted mark newton for info on how to do this with the new cms.

[alesj]

org.jboss.reflect.spi shouldn't contain Javassist specific classes.

Make it spi.javassist or something similar.
e.g. we sometimes use helpers pckg

[alesj]

 System.out.println("Number of fields before remove: "+ctClass.getDeclaredFields().length);

:-)
I guess this is gonna be log.trace or removed?

And if you could just add default javadocs,
so that the IDE is not all red. :-)

[alesj]

public class DummyClassPoolFactory implements ClassPoolFactory
{

 public ClassPool getPoolForLoader(ClassLoader cl)
 {
 return ClassPool.getDefault();
 }

}

Why Dummy if it's default?

[stalep]

"alesj" wrote:
org.jboss.reflect.spi shouldn't contain Javassist specific classes.

Make it spi.javassist or something similar.
e.g. we sometimes use helpers pckg

i moved the Body implementations to org.jboss.reflect.plugins.javassist. i was kinda uncertain about where they should be placed since they didnt expose any javassist classes and they are needed to use the mutable classes.
- but the user need to specify javassist specific implementations when he want to create a mutable object, so i guess it fits in the javassist package too.

"alesj" wrote:
I guess this is gonna be log.trace or removed?

its already removed, totally forgot to remove them.

"alesj" wrote:

public class DummyClassPoolFactory implements ClassPoolFactory
{

 public ClassPool getPoolForLoader(ClassLoader cl)
 {
 return ClassPool.getDefault();
 }

}

Why Dummy if it's default?

i made those in the beginning hoping that kabir would finish his classloading stuff before i added this to trunk. when it didnt happen i kept the dummy just to show that this is something that will be changed later. this isnt something that is exposed to the user, so i felt it was ok to just leave it.
- its the same code that was used earlier though, so it works like before.

[kabirkhan]

i made those in the beginning hoping that kabir would finish his classloading stuff before i added this to trunk.

We need a release of jboss-reflect before we can start implementing its ClassPoolFactory :-)

The implementation in AOP will be very simple

class AOPReflectClassPoolFactoryImpl implements ClassPoolFactory
{
 public ClassPool getPoolForLoader(ClassLoader cl)
 {
 return AOPClassPoolRepository.getInstance().registerClassLoader(cl);
 }
}

The question is when/how do we put this into jboss-reflect? Do we initialise it with a bean in AS conf/bootstrap/aop.xml?