Say you have two versions of a jar, "myjar10.jar", and "myjar11.jar" which are two versions of the same API. Assume the API contains a sealed package called "sealme" and a class named "Foo.class". Now assume Foo.class version 1.0 has a method named "oldMethod(int)", but version 1.1 has it as "oldMethod(double)".

If your application uses both methods (by mistake or design), the JVM will attempt to load "oldMethod(int)" from the 1.0 jar, and "oldMethod(double)" from the 1.1 jar, and it will detect the seal has been breached and toss the sealing violation exception.

You have to track down which jars are duplicating a sealed package, and remove all of the duplicates from the classpath.

This feature does make it difficult to "patch" or "override" classes by prepending to the classpath a jar containing replacement classes.
2001-May-25 11:23am gyles19@visi.com

The solution here is to reorder your project's classpath to place JAXP1.1 jars at the start of the classpath, prior to Tomcat's jar in the list of jars. You can do this by defining a required library for the JAXP 1.1 jars (xalan.jar, xerces.jar, crimson.jar, etc) and using the "move up/move down" buttons to place them at the top of the project's required library list. This should cause them to appear before the Tomcat jars in the runtime classpath and should solve the problem.

If that doesn't work, you may have to resort to using -Djava.class.path=... in the project's VMParameters field. This completely overrides the classpath Jbuilder is trying to provide, including the JDK's jars, so you'll have to specify everything the project needs to run by typing it manually (or using a cut/paste operation from the message pane's display of a previous launch.)
2001-Jun-06 9:47pm gyles19@visi.com

  Are there any tools available to help diagnose classpath problems?