----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, May 28, 2002 7:05 PM Subject: Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch (?)attached
> > Hi, > > > > I believe I have found a bug (or a problem at least) with the way Tomcat > > handles associating webapp contexts to JNDI naming contexts. > > > > ContextBindings.java, which apparently handles these associations does > > not account for the fact that a web application may have its own > > ClassLoader. I am trying to use Apache Cocoon which does this. I've > > properly enlisted the object I want in the namespace using the > > server.xml file and the web.xml file. After Tomcat creates this > > NamingContext, it "binds" it to Cocoon's context in > > ContextBindings.java, using the current ClassLoader as a key, which > > happens to be Tomcat's WebAppClassLoader. Cocoon provides its own > > ClassLoader (because it is a rather complex beast :-), so when I try to > > get to my object in the namespace it can't be found (even though its > > parent ClassLoader is the correct WebAppClassLoader) > > > > This may or may not be appropriate, but I've found that it works for > > me. I've modified the following methods in ContextBindings.java: > > > > getClassLoader() > > getClassLoaderName() > > isClassLoaderBound() > > > > so that they check the hashtable for the current ClassLoader, and > > continue to search up the heirarchy by looking at that ClassLoader's > > parent -- returning success at the first match, and returning failure > > once it has been all the way up the heirarchy. A method I did not > > modify was unbindClassLoader() -- I'll leave that to further discussion > > because (if my solution is acceptable) I'm not sure if it is appropriate > > to leave it or change it. > > > > This patch is against CVS revision 1.4 of the file, which I got from the > > source distribution of Tomcat 4.0.4 beta 3. > > The J2EE ENC is, by definition, a J2EE features. Applications which would > like to use it should comply with the J2EE model, which implies: > - not forking threads > - not creating classloaders > - running inside a security manager > > Cocoon does not adhere to this model, and will probably have problems using > the J2EE ENC in other app servers. To get around this, it would be better > for Cocoon to set the webapp CL as the thread context CL during the > processing of the user code. > > Since this patch does not seem to introduce any problems and improves > robustness, I think I'll apply it to the 4.1.x codebase. > > Remy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
