cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@apache.org>
Subject [FYI:Fw from Tomcat list] Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch (?)attached
Date Wed, 29 May 2002 06:21:48 GMT
----- Original Message -----
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message