cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: classpath problems with cocoon2
Date Fri, 16 Feb 2001 13:41:28 GMT
Stefano Mazzocchi wrote:
> 
> Berin Loritsch wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > This is probably related with what Berin was talking about, but Cocoon2
> > > doesn't work.
> > >
> > > Apart from a URLFactory bug which I just fixed, it seems that no matter
> > > what I do I either end up having a "sealing" exception from Tomcat (if I
> > > place everything into /WEB-INF/lib/) or compilation issues with the
> > > sitemap (if I place everything into CATALINA_HOME/lib/)
> > >
> > > I noted one thing: Catalina doesn't add the libraries found in
> > > CATALINA_HOST/lib/ in the classpath environment passed to the servlet
> > > contexts.
> > >
> > > How does Jasper work, then?
> > >
> > > Berin, what servlet engine are you using?
> >
> > I am using Tomcat 3.2.1 (and <sheepishly>IBM WebSphere</sheepishly>).
> > IBM WebSphere requires all the jars in CLASSPATH (yuck).  My next solution
> > is to have a different ServletEngine depending on Servlet 2.2 or Servlet
> > 2.3--Servlet 2.3 engine won't do classloader juggling while Servlet 2.2
> > will.  That will satisfy both our concerns.
> >
> > I have not yet seen any clean way around the JAXP 1.1 vs. 1.0 issues.
> > That is the one thing that is going to keep us from doing one complete
> > jar.
> >
> > Temporary solution is to place Xerces in CATALINA_HOST/lib/ as well--
> > breaking Jasper.
> 
> By 'unsealing' jaxp.jar and crimson.jar and adding 'servlet.jar' to the
> context classpath attribute, Cocoon2 works perfectly out of a single jar
> on Catalina.
> 
> I believe this is a pretty damn good result given the problems we face
> and there are no side effects in these changes.

Yeah, but how many other implementations do we have to worry about.
BEA is another one--although I will attempt to unseal their XML parser
to get the same results.

Jar Sealing was introduced to keep malicious code from attaching itself
in your packages during run-time.  Now, on an XML parser there is little
damage that malicious code can perform (besides to itself), but in many
commercial AppServers like BEA and IBM they place many different
components in the same jar.

I introduced two Servlets in the Cocoon archives.  The trusting one
CocoonServlet that assumes you have a sane invironment, and an
untrusting one called ParanoidCocoonServlet--required for IBM WebSphere
with broken ClassLoaders (you can't get resources from its classloaders).

Unsealing jars in production environments is a risky thing and voids
warranty on commercial systems.  We still need to look for a more
elegant solution.

I thought that the Servlet 2.3 spec required that the Webapp was
COMPLETELY separated from the Servlet Container--Mainly for the
JAXP and XML parsing issues.  For that reason I would site Catalina
as breaking the spec...

Mime
View raw message