"alesj" wrote : How do we use it elsewhere/before? Before I added those getType.getClassLoader() calls, the null classloader was being used for loading and creating ctClasses instead. I don't think that classloader is retrieved elsewhere,apart from BasicClassAdapter.getClassLoader(), that also invokes getType() to get to the ClassLoader. "alesj" wrote : Looking at the Javassist Reflect usage, it seems we need to change it a bit. | | | | public Class<? extends Object> getType() | | { | | if(clazz == null) | | clazz = JavassistUtil.ctClassToClass(ctClass); | | | | return clazz; | | } | | | | This first delegates the loading to JavassistUtil.class.getClassLoader() and only then to CtClass::toClass. | Meaning we wouldn't use our new Classpool notion first, only after it would fail via first try. Don't you mean that, if the ModifiableClassInfo is modified, it delegates the loading to CtClass::toClass first, and only then to the JavassistUtil.class.getClassLoader()? IMO, this is correct, given that CtClass.toClass() uses the ClassPool and the ClassLoader associated with the ClassPool in order to load the class. Still, the JavassistUtil class contains a few bugs, because it is not using the correct classpool on the remaining methods. "alesj" wrote : | Perhaps new getClassLoader method on TypeInfo? I think that that is the ideal. The getType method has the collateral effect that the MutableClassinfo can no longer be edited after it has been loaded. The correct way of retrieving the class loader would be: ctClass.getClassPool().getClassLoader This could be easily done if we added a getClassLoader() method to TypeInfo. "alesj" wrote : btw: don't forget to check for security or add permission blocks on who can use it Ok! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260375#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...