cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [bug] welcome to the bleeding edge :(
Date Fri, 16 Feb 2001 00:26:02 GMT
Stefano Mazzocchi wrote:

> "Craig R. McClanahan" wrote:
> >
> > Stefano Mazzocchi wrote:
> >
> > > This morning I said: 'ok, let's how C2 has grown up'. So, I did a fresh
> > > CVS checkout, followed the INSTALL file and here is what I got
> > >
> > >   java.lang.SecurityException: sealing violation
> > >
> > > which smells of Tomcat problem, but prevents us from deploying Cocoon2
> > > as copy-cocoon.war-and-forget as we wanted.
> > >
> >
> > Indirectly Tomcat-related.  It is actually caused by the fact that the JAXP 1.1
JAR files are sealed.  It appears that there is no way to override a sealed JAR from a
> > JAR file loaded from the webapp itself.  :-(
> >
> > So far, replacing the JAXP jar files (jaxp.jar and crimson.jar) with the xerces.jar
from Xerces 2.0 alpha seems to still work, and allows the "plug and play" we all
> > want.

This turns out not to be quite true any longer -- 2.0alpha doesn't implement everything that
Jasper needs yet for parsing JSP pages in XML syntax.

> I have a much simpler solution: 'unseal' jaxp.jar and crimson.jar in the
> catalina CVS.

Well, jaxp.jar and crimson.jar are not actually stored in the CVS tree ...but that's a whole
different discussion.

As appealing as this solution is, it seems risky on several counts:

* How do we know that the correct functionality of jaxp.jar and crimson.jar
  doesn't count on the fact that they are sealed?  (Edwin Goei, who works
  on JAXP, claims he has no knowledge of any such dependencies, or
  why it was ever sealed in the first place, but it's definitely not clear).

* What happens when a new release of JAXP comes out (as the final
  release did just today)?  Naive users are going to upgrade, and suddenly
  all their Cocoon apps will break again.

The right long term answer is to make Jasper load its own parser (so that the class loader
hierarchy exposed to web apps is not polluted by *any* parser).  It's just going
to take a little time to pull this off.

By the way, could someone fill me in on the issues with servlet.jar (and a recipie to reproduce
it)?  It's currently in the "bin" directory so that the same classes are
seen by both the Catalina internal class loader and all the web apps -- what problems is it
causing for Cocoon?


View raw message