You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Haraburda <da...@haraburda.com> on 2002/06/03 09:31:12 UTC
CocoonSerlvet Patch (init-classloader param)
Hi,
I have written a small patch to address some class loading issues in
CocoonServlet. In a previous (and rather lengthy) post on Friday I
detailed what I thought were some problems with Cocoon's
RepositoryClassLoader. I now see that this class loader is required for
the compiling and loading of XSP pages (and other things such as the
sitemap), although I do not think this ClassLoader should be used when
user code is executed.
In my previous post, I described my reasoning for this, but the two main
reasons are that:
1) The Java API docs imply that it is a Thread's creator's
responsibility to set the ContextClassLoader (CocoonServlet does this
inappropriately, I believe), and;
2) When Cocoon sets its own ClassLoader as ContextClassLoader, this
breaks Tomcat's JNDI implementation because of the way Tomcat ties
Environment Naming Contexts to ClassLoaders (see my previous post)
Although it is my personal opinion that Cocoon shouldn't be setting the
ContextClassLoader at all, my patch checks to make sure the
"init-classloader" param is set to true before it does so. Right now,
CocoonServlet ignores this parameter with a note in the code saying
"HACK for reducing class loader problems." -- which, I was also
wondering if someone could elaborate on what kind of problems are being
referred to here?
I see that BootstrapServlet does the same thing, except with
ParanoidClassLoader, but I've left this alone for now.
I'd like some feedback, and if positive, I will go ahead and submit my
patch to Bugzilla. :-)
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: CocoonSerlvet Patch (init-classloader param)
Posted by David Haraburda <da...@haraburda.com>.
On Thu, 2002-06-06 at 14:46, John Morrison wrote:
> > ... Tomcat ...
> > ... Tomcat ...
>
> Unfortunately, not everyone can run such a well
> behaved servlet engine.
True, but being the reference implementation for both the Servlet and
JSP specs, Cocoon shouldn't (for a long time anyway :-) have this sort
of problem.
> When Cocoon (2) was started most of the engines
> *didn't* correctly implement classloaders.
>
This is certainly understandable -- but I believe non-standard behavior
should be "off" by default, not on. If there are those out there still
experiencing issues with classloaders (that they are sure are problems
with Cocoon and/or servlet engines), I wouldn't mind hearing about them,
because I'd like to look into them (my motivation for trying to raise
this issue in the first place)
> J.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: CocoonSerlvet Patch (init-classloader param)
Posted by John Morrison <jo...@ntlworld.com>.
> ... Tomcat ...
> ... Tomcat ...
Unfortunately, not everyone can run such a well
behaved servlet engine.
When Cocoon (2) was started most of the engines
*didn't* correctly implement classloaders.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: CocoonSerlvet Patch (init-classloader param)
Posted by David Haraburda <da...@haraburda.com>.
Hi Carsten,
On Thu, 2002-06-06 at 07:31, Carsten Ziegeler wrote:
> Hi David,
>
>
> I don't now the problem, but as far as I can tell, the init-classloader
> param is evaluated. In CocoonServlet, line 306 (current CVS):
> this.addClassDirs = "true".equalsIgnoreCase(value) ||
> "yes".equalsIgnoreCase(value);
>
> and this boolean is used at several places throughout the servlet class.
>
> So, what does your patch change?
>
> Carsten
>
This parameter is evaluated, but it is only used when the servlet is
checking to see if it should "build its own classpath" (something I
don't think it should be doing anyway). Regardless of what the
init-classloader parameter is set to, user-level code will always be
executed with the RepositoryClassLoader, which breaks JNDI in Tomcat.
Take a look at line 936 of CocoonServlet.java (the latest CVS revision):
/* HACK for reducing class loader
problems. */
/* example: xalan extensions fail if someone adds xalan jars in
tomcat3.2.1/lib */
try {
Thread.currentThread().setContextClassLoader(classLoader);
} catch (Exception e){}
The ContextClassLoader is set, regardless of the init-classloader
parameter. My patch (attached) simply adds checks for this parameter,
here and a few other needed places -- although I would like to emphasize
that I think this should be considered a temporary solution, because
(just to reiterate :-), the Java API docs imply that it is a Thread's
creator's responsbility to set the ContextClassLoader (which Tomcat does
appropriatley), and the J2EE spec also states that this is the
container's responsibility (which again would be Tomcat) -- so
certainly, although RepositoryClassLoader is obviously needed for
internal purposes, it should never be there when user-level code is
being executed. But apparently there were/are some very strange class
loading issues that prompted this "HACK"... does anyone know what they
are?
Thanks,
David
RE: CocoonSerlvet Patch (init-classloader param)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi David,
>
> Hi,
>
> I have written a small patch to address some class loading issues in
> CocoonServlet. In a previous (and rather lengthy) post on Friday I
> detailed what I thought were some problems with Cocoon's
> RepositoryClassLoader. I now see that this class loader is required for
> the compiling and loading of XSP pages (and other things such as the
> sitemap), although I do not think this ClassLoader should be used when
> user code is executed.
>
> In my previous post, I described my reasoning for this, but the two main
> reasons are that:
>
> 1) The Java API docs imply that it is a Thread's creator's
> responsibility to set the ContextClassLoader (CocoonServlet does this
> inappropriately, I believe), and;
>
> 2) When Cocoon sets its own ClassLoader as ContextClassLoader, this
> breaks Tomcat's JNDI implementation because of the way Tomcat ties
> Environment Naming Contexts to ClassLoaders (see my previous post)
>
> Although it is my personal opinion that Cocoon shouldn't be setting the
> ContextClassLoader at all, my patch checks to make sure the
> "init-classloader" param is set to true before it does so. Right now,
> CocoonServlet ignores this parameter with a note in the code saying
> "HACK for reducing class loader problems." -- which, I was also
> wondering if someone could elaborate on what kind of problems are being
> referred to here?
I don't now the problem, but as far as I can tell, the init-classloader
param is evaluated. In CocoonServlet, line 306 (current CVS):
this.addClassDirs = "true".equalsIgnoreCase(value) ||
"yes".equalsIgnoreCase(value);
and this boolean is used at several places throughout the servlet class.
So, what does your patch change?
Carsten
>
> I see that BootstrapServlet does the same thing, except with
> ParanoidClassLoader, but I've left this alone for now.
>
> I'd like some feedback, and if positive, I will go ahead and submit my
> patch to Bugzilla. :-)
>
> Thanks,
>
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org