Bill Pfeiffer wrote:
>
> Classpath is not set (ie set to empty) when starting Tomcat.
With Tomcat 4.0 using standard startup scripts, this does not matter --
the user's CLASSPATH variable is totally ignored.
My web app
> does include some jars, none of which should clash with Tomcat.
>
My understanding is that a "sealing violation" is not caused by a
conflict with Tomcat -- rather, it's caused when you try to load a class
A in a particular package from one JAR, and class B from the same
package from another JAR. I do not believe it matters whether it's the
same class loader or not; the issue is that a sealed package should be
completely loaded from a single JAR.
But I'm not done doing my own research to understand this problem,
either.
> Any other ideas on what to start looking for in terms of a clash?. The
> class in question appears to be one of my own in the WEB-INF/class
> directory.
Do you by chance have some un-JAR'd classes under WEB-INF/classes, and
some other classes in the same package found in a JAR file?
>
> Thanks,
>
> Bill Pfeiffer
Craig McClanahan
