cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [bug] welcome to the bleeding edge :(
Date Fri, 16 Feb 2001 13:45:44 GMT
"Craig R. McClanahan" wrote:
> 
> 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?

No it has to do with Cocoon including it in the manual Classpath that
it needs to compile classes.  I think I am going to add an attribute
to CocoonServlet so that we can manually expand the Classpath to include
the Servlet jar and any other jar not directly accessible from the
WEB-INF/ libraries or System Classpath.

Mime
View raw message