You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by David Haraburda <da...@haraburda.com> on 2002/05/28 10:00:17 UTC
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.
Hope this helps others with the same problem.
Thanks,
David Haraburda
[FYI:Fw from Tomcat list] Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch (?)attached
Posted by Nicola Ken Barozzi <ni...@apache.org>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@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
Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch
(?)attached
Posted by 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>
Re: JNDI/Webapp ClassLoader Bug (ContextBindings.java), patch (?)attached
Posted by Remy Maucherat <re...@apache.org>.
> 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>