On Mon, 23 Jul 2001, Stephane Bailliez wrote: > > Assuming ant is run inside a webapp or similar environment ( > > where user code is loaded in a separate classloader ), there are few > > cases where the current code will not work. > > What are some known problems about the use of Class.forName() instead of the > context classloader ? > I read here and there some bug reports in some JDK, but this is not that > clear to me.
If ant.jar is located in CLASSPATH or in the container equivalent ( tomcat/lib. tomcat/lib/common, catalina/lib/??? ) and the class it needs is located in a webapplication ( that is calling ant ), Class.forName will use the class loader that loaded ant ( which will be an ancestor of the webapp ). That means ant can't find tasks defined in the webapp, resources, etc. > The class.forName is supposed to use the caller classloader from what I can > see in the source. > However it is not clear for me what the caller classloader is and if it > works in all cases. > Assuming you are in class A part of the webapp (and thus loaded by the > context classloader), doing a Class.forName in a method of class A, are we > supposed to have: > context classloader == ClassLoader.getCallerClassLoader() == > A.class.getClassLoader() ? True only if A is also part of the webapp ( and not included in CLASSPATH or any parent of the webapp classloader ). In servlet2.3 the rules are more interesting, sometimes A is loaded by webapp classloader ( breaking the delegation rule ) - sometimes by the parents. Costin
