#3 Sealing violation

[Stephen Garbarini]

I get the following "sealing violation" when I run with winstone 0.9.8 (or 0.9.9), but I do not get the same problem when running with earlier versions. I've looked up the error and it seems that I have multiple jar files providing the same package... I'm looking into that, but it would be nice to know why the problem only crops up with later versions of winstone. Any help would be appreciated, thanks.

C:\servers\winstone>C:\jdk\x86\jdk1.5.0_11\bin\java.exe -classpath winstone-0.9.8.jar;C:\servers\db2jcc.jar;C:\servers\m
ail.jar -Xmx200M winstone.Launcher --warfile=C:\PSx\PSNextRelease\psnextRel.war --realmClassName=winstone.realm.FileReal
m --fileRealm.configFile=C:\servers\winstone\users.xml --httpPort=8089 --prefix=/psnextRel --debug=4
[Winstone 2007/10/02 21:46:35] - Untrapped Error in Servlet
java.lang.SecurityException: sealing violation: can't seal package org.w3c.dom: already loaded
at java.net.URLClassLoader.defineClass(URLClassLoader.java:235)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at winstone.classLoader.WebappClassLoader.loadClass(WebappClassLoader.java:44)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at com.sciforma.psnext.webstart.servlet.JnlpDownloadServlet.init(DashoA10*..:64)
at winstone.ServletConfiguration.ensureInitialization(ServletConfiguration.java:183)
at winstone.ServletConfiguration.execute(ServletConfiguration.java:225)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
at java.lang.Thread.run(Thread.java:595)

[Rick Knowles]

Logged In: YES
user_id=716353
Originator: NO

As a short term workaround, try adding the command line arg: --preferredClassLoader=java.net.URLClassLoader

This will disable winstone's webapp class loader, which seems to be the source of the problem.

[Stephen Garbarini]

Logged In: YES
user_id=717046
Originator: YES

The preferredClassLoader option on the command line fixed the problem... thank you.

[Rick Knowles]

Logged In: YES
user_id=716353
Originator: NO

I've just applied a patch in CVS (from James Berry) that would hopefully address this problem. Please give it a try and re-open this bug if it's still broken.

Thanks,

rick