"The problem with the this.getClass().getClassLoader().loadClass(String) is that it triggers a seach relative to the classloader in which "this" is defined. If "this" is in a classloader higher than the class you trying to load then you out of luck wheras the context classloader is the lowest classloader in the stack relative to your implementation."
I agree. The example I was thinking about assumed that "this" and the class to load are in the same CL. Maybe I should have copy-pasted the text I was referring to: "Many Java tools internally use Class.forName(String).newInstance() to instantiate some part of its internal functionality. This works if the class's Jar is mounted at the top-level system classloader. In the case of many Avalon containers, the Jar in question will actually be mounted in a classloader at some other point in a tree of classloaders. Thus Class.forName() will fail with ClassNotFoundException if running in a container." as the text says "to instantiate some part of its internal functionality" I think is talking about a class which is in the same classloader as "this". In this case, wouldn't Class.forName(String) and this.getClass().getClassLoader().loadClass(String) do the same? I also think (correct me if I'm wrong) that (in this example with "this" and the loaded class in the same CL) Thread.currentThread().getContextClassLoader().loadClass(String) would do the same as the two other options, as long as the Context Classloader was set properly before calling the tools' class. This dependence of the Context ClassLoader being handled properly makes me doubt about which option to use. thanks a lot, Horaci --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
