Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch (?)attached

[David Haraburda <da...@haraburda.com>]

Hi Remy,

Thanks for responding and thanks for adding the patch to 4.1.  I do have a
question for you though:

Looking at the J2EE spec, I can't find anything that says applications shouldn't
create ClassLoaders, although you do say it is "implied".  I am just wondering,
where do you find this implication?  I realize that most web applications
probably don't need to create their own classloaders, but (I've only glanced at
this part of the Cocoon code) it seems to be justified at first look in this
case.

Just looking for some clarification.

Thanks again,

David

Remy Maucherat wrote:

> > 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>