Hi, -----Ursprüngliche Nachricht----- >Von: Jason Dillon [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 27. Februar 2002 03:37 >An: [EMAIL PROTECTED] >Betreff: [JBoss-dev] Class.forName() problem
> return forName0(className, true, ClassLoader.getCallerClassLoader()); >If I understand this correctly, then the return of >ClassLoader.getCallerClassLoader() will be the system or rather bootsrap >CL, since that is what has loaded URL (URL.class.getClassLoader() >returns null). Actually, as far as my little brain can remember, getCallerClassLoader() will return the Class.getClassLoader() of exactly that class that has last been entered by the execution stack frame (yes, itīs a such difficult and useless construct!). Hence, if the class that contains the Class.forName() code has been loaded by the thread context classloader (that is the case, I would say, 90% of the time), there will be no problem (aeh, see below, my intuition says that there can still be problems with the VM going nuts, afterwards ...) If you have a generic class, e.g., a JSP-framework, sitting in, e.g., the bootclasspath, that is called by the specific application logic with a string-based classname and does then a Class.forName with that string, e.g., to instantiate a specific Handler located in the application jar, you are lost ... Furthermore, I suspect the forName0 natives to do weird things with in-VM class caching (otherwise they could have easily delegated ClassLoader.loadClass(className,true) or such). I once had some test code that showed that after cycling some classloaders alltogether, you were still able to get references to "old" classes/classloaders from the new classes/classloaders. Arenīt there still some ClassCastExceptions appearing here and there which nobody can yet explain? Class.forName() isnīt maybe buggy for the SUN guys because they canīt imagine somebody aberrating from their shitty tree classloading delegation model (even more since the advent JDK1.4, because if I got that right, they built classloader cycling into the VM, so they donīt see any need for alternative models, IMHO). But itīs a no-no in our delegation model. CGJ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
