At 04:08 21/1/01 -0800, Craig R. McClanahan wrote:
>Sealing is one "user error" issue that will cause classloading to fail inside
>Tomcat. Another is the fact that a particular class can only see other
classes
>in its own classloaders, and parents of that classloader, but not
children. The
>net effect is that some class libraries will NOT work unless you put them
inside
>WEB-INF/lib, because they need to be able to access other classes specific to
>that webapp.
>
>Consider the following scenario:
>* Class L is in a shared library ($TOMCAT_HOME/lib for Tomcat)
>* Class W is in WEB-INF/classes or WEB-INF/lib/*.jar
>* You pass the fully qualified class name of class W to a
> method in class L whose job is to instantiate a new object
> of this class.
>* Class L does essentially the following:
> Class wClass = Class.forName(wClassName);
> and encounters ClassNotFoundException.
>
>The reason for the exception is that Class L was loaded from the shared
library
>classloader (which is the parent of all webapp classloaders in Tomcat).
>Therefore, it cannot see into the webapp to find class W.
I was under the impression that Class.forName() loaded classes from the
context classloader. So in theory the above would work if context
classloader was set up correctly. The only thing that wouldn't work is
something like
Class wClass = getClass().getClassLoader().loadClass( wClassName );
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
