cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: [bug] welcome to the bleeding edge :(
Date Thu, 15 Feb 2001 16:53:53 GMT
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.

>
> 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.

>
> 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.

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



Mime
View raw message