This content has been marked as final.
Show 4 replies
-
1. Re: Getting to a ClassInfo's ClassLoader
alesj Oct 14, 2009 11:43 AM (in response to flavia.rainone)How do we use it elsewhere/before?
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.
Perhaps new getClassLoader method on TypeInfo?
btw: don't forget to check for security or add permission blocks on who can use it -
2. Re: Getting to a ClassInfo's ClassLoader
flavia.rainone Oct 14, 2009 2:15 PM (in response to flavia.rainone)"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! -
3. Re: Getting to a ClassInfo's ClassLoader
alesj Oct 14, 2009 3:47 PM (in response to flavia.rainone)"flavia.rainone@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@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. -
4. Re: Getting to a ClassInfo's ClassLoader
alesj Oct 15, 2009 2:45 AM (in response to flavia.rainone)"alesj" wrote:
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.
- https://jira.jboss.org/jira/browse/JBREFLECT-61