cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [bug] welcome to the bleeding edge :(
Date Thu, 15 Feb 2001 18:31:56 GMT
"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.

I have a much simpler solution: 'unseal' jaxp.jar and crimson.jar in the
catalina CVS.
 
> >
> > The full log file is attached (the classloading stacktrace is pretty
> > impressively long, BTW. Are we sure this isn't going to kill
> > performance?)
> >
> 
> The classloader piece is because there is a hierarchy of class loaders in Catalina, to
serve various needs, and the delegation model walks up the chain.
> 
> The Catalina piece is because we use the stack for virtually all per-request state information,
thanks to the pipelined "chain of responsibility" design pattern.  The
> tradeoff we get for deeper call stacks is that none of the processing modules have to
worry about maintaining per-thread state (in Hashtables, ThreadLocals, or such)
> -- they just use local variables.  The net-net so far looks like a huge win on performance.

I fully trust your judgement here.
 
> >
> > For now, I'll place the libraries in the library file and live with
> > that, but hey, Craig, what about kicking the JDK team in the ass for
> > fixing all these stinking classloading problems with JDK 1.4? (which is
> > supposed to be coming up real soon now, right?)
> >
> 
> It's actually the JAXP team in this particular scenario.  Unfortunately, release timing
is going to mess us up.

Can't we simply remove that "sealed: true" from the manifest and live
well?
 
> The real solution (from the Tomcat 4.0 perspective) will be to have Jasper load the XML
parser it needs from a separate class loader, instead of exposing that parser
> to all the webapps.  This solution is going to take a little longer.
> 
> >
> > The java classloader concept is extremely powerful, but it has created
> > problems ever since it was created (starting with the totally stupid
> > classpath concept!) Oh god.
> >
> 
> The 1.4 environment will be different, and is coming along.  I don't know if it helps
us in the near future or not, since we'll need to maintain the ability to run on
> 1.2 or 1.3 for a long time to come.
> 
> >
> > --
> > Stefano Mazzocchi      One must still have chaos in oneself to be
> >                           able to give birth to a dancing star.
> > <stefano@apache.org>                             Friedrich Nietzsche
> > --------------------------------------------------------------------
> >
> 
> Craig


-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message