tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Bailliez" <>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime
Date Sun, 11 Feb 2001 23:54:02 GMT
----- Original Message -----
From: <>

> Someone who needs only jasper can take the utils and jasper package.
> ( duplicating some of the classes in 2 package may have negative impact on
> class loading - it may throw "Sealing" exceptions )

My apologize for my intervention in this discussion, but I second you on

Here are my reasons:

I have been playing a lot lastly with jaxp1.1 and crimson who had the good
idea (but surprising at the beginning) to do package sealing. This caused
lots of problems in my development environment because a lot of people are
packaging the jars a little bit like: "put everything we can inside it to
deliver only a single jar".

For instance it was impossible to run Resin 1.1.4 with crimson. Why ?
Because the w3c and sax interfaces were buried into Resin.

Right now if you want to use the latest xalan and xerces, you'll have 2
times jaxp, 2 times dom and 2 times sax. You want to try jaxp1.1ea2..mmm you
have to play with the classpath order instead of simply 'replacing' it.

If you look at the existing JMS providers and that you want to try them all
you can be pretty sure you don't need all interfaces around jms ... each of
them has interfaces packaged into the jar. If you mix all JMS providers, you
end up with the full necessary classpath to compile whatever you're doing
with jms.

Another tricky thing, I was using XT for XSL transformation and another web
module was using the old sax.jar in an applet. The lib repository was a
single .lib directory with all jars and each module was referencing its
needed jar.
When I was running my XT dependent module (who was using crimson), I ended
up with a sealing violation. It took me a while to realize was due
to xt that had a Class-Path: sax.jar in its manifest and was thus loading a
jar I didn't want.

That is, in a complex product, you probably end up with 10 times the
necessary classes and you'd better have the exact same version otherwise
you'll be doing some tricks with the classpath order until you realize its
not possible in certain cases, so what choice do you have ? cut the
distibuted jar in pieces ?

Just my $0.01.


View raw message