Todd, this is mostly correct. This problem occurs (usually) because there are two different versions of the SAME class in two different JARs, at least one of which is "sealed" in its manifest. What frequently happens is a class from JAR A gets loaded first, and then some code within that class tries to load a class that was inadvertently loaded from JAR B, hence the sealing violation. I've included part of an earlier thread on this below, but the easy fix is the following, since these JARs are not signed: Extract the MANIFEST.MF file. Edit it and remove the entire "Sealed" property line. Do a "jar -uvfm <jarfilename.jar> META-INF/MANIFEST.MF" to update the JAR with this edited manifest. Do this for both JARs. problem solved, albeit not elegantly. I think this happens when you mix different versions of jar files. Have you tried blanking out your classpath before running jboss? You might be able to find a more detailed answer in the message archives since I remember seeing this answered before. - Todd Chaffee > I get package sealing violations when I run my web app on Tomcat 4.0 m3 and > m4. I never got these with previous releases, and it looks to me as if the > cause is the addition of the sealed crimson.jar JAR file to the library. > Problem is that my app uses JDOM b4, which is using Xerces 1.1.2, and Xerces > contains a bunch of JAXP/DOM/SAX classes that also appear in crimson.jar > (hence the sealing violation). > Does anybody have any advice on how best to handle this situation? I guess > that one way is to remove the duplicate classes from either crimson.jar or > xerces_1_1_2.jar, but that seems less than ideal, and could easily lead to > breakage. Maybe some solution involving loading the JARs with different > class loaders? > > Thanks, > Willie Welcome to the wonderful world of classloaders :-). You're correct -- trying to remove classes from one or the other of the JAR files is not going to work at all. Each library will be depending on its own internal implementation of those classes. The crimson.jar file is placed in $CATALINA_HOME/lib (and therefore visible to web apps) because Jasper needs a JAXP-1.1 compatible parser. It would be technically feasible for Jasper to load its own XML parser in a private classloader, but this is not a trivial amount of work. Once Xerces is upgraded to JAXP-1.1 compatibility you will simply be able to use Xerces instead (and thus not have these conflicts). If your app does not need JSP, you could simply remove crimson.jar from $CATALINA_HOME/lib (you will want to comment out the JSP servlet in $CATALINA_HOME/conf/web.xml as well). If you do, I'm afraid there isn't much that can be done in the short run until all the parsers catch back up with JAXP compatibility again. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
