[jboss-user] [JBoss Microcontainer Users] - Re: Getting to a ClassInfo's ClassLoader

"flavia.rainone(a)jboss.com" wrote : | 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. | If modified, we just try if we can still load it. | if(ct.isModified()) | { | try | { | ct.toClass(); | } | catch (CannotCompileException e) | { | throw new org.jboss.reflect.spi.CannotCompileException(e.toString()); | } | } | And yes, JavassistUtil definitely needs fixing. "flavia.rainone(a)jboss.com" wrote : | "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. OK, this looks reasonable, as to delay class creation as long as we can. Like I said, just make sure - perhaps it's already part of javassist code - that there is security enforcement. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260397#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...