aspose file tools*
The moose likes Java in General and the fly likes java.lang.SecurityException: sealing violation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "java.lang.SecurityException: sealing violation" Watch "java.lang.SecurityException: sealing violation" New topic
Author

java.lang.SecurityException: sealing violation

Stefan Gerber
Ranch Hand

Joined: Mar 08, 2008
Posts: 33
Hello,
i get the following exception when i try to use a Jax-ws webservice. I have endorsed some jars to use a newer version of jaxws.
Anyboy an idea what the problem is?

2011/05/13 11:41:51.011 +0200 -> [SEVERE]: java.util.ServiceConfigurationError: javax.xml.ws.spi.Provider: Provider com.sun.xml.ws.spi.ProviderImpl could not be instantiated: java.lang.ExceptionInInitializerError
at java.util.ServiceLoader.fail(ServiceLoader.java:207)
at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
at javax.xml.ws.spi.Provider.getProviderUsingServiceLoader(Provider.java:180)
at javax.xml.ws.spi.Provider.provider(Provider.java:140)
at javax.xml.ws.Service.<init>(Service.java:92)
at javax.xml.ws.Service.create(Service.java:722)
at jaxws.util.WebServiceFactory.getWebService(WebServiceFactory.java:102)
at service.mandant.threads.BaseRunnableImpl.run(BaseRunnableImpl.java:84)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
... 22 more
Caused by: java.lang.SecurityException: sealing violation: can't seal package com.sun.xml.bind: already loaded
at java.net.URLClassLoader.defineClass(URLClassLoader.java:242)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$3.run(JAXBContextImpl.java:304)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$3.run(JAXBContextImpl.java:303)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:302)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1170)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:228)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:215)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:401)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:264)
at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:262)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.ws.spi.ProviderImpl.getEPRJaxbContext(ProviderImpl.java:261)
at com.sun.xml.ws.spi.ProviderImpl.<clinit>(ProviderImpl.java:95)
... 25 more
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42289
    
  64
My guess (more like a hunch, actually) would be that some of the classes in the com.sun.xml.bind package are present in the classpath more than once, and loaded by a different classloader than some of the other JAX-WS classes.


Ping & DNS - my free Android networking tools app
Jason Casey
Greenhorn

Joined: Feb 15, 2011
Posts: 4
Stefan,

The message "sealing violation: can't seal package ... already loaded" should occur when loading a class that extends another 'sealed' class. I.e. extends a class that cannot be extended (according to this article). However, I imagine this exception may also occur in some special situations where multiple versions of the same class are being loaded. There are some goog articles on the web for diagnosing ClassLoader issues such as this.
Stefan Gerber
Ranch Hand

Joined: Mar 08, 2008
Posts: 33
Hello,
Thanks for the answers. Hmm i could be possible that different versions of a class are loaded because this exception only happens when i endores the jaxws jars.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42289
    
  64
Make sure you endorse all the JAXB libraries as well.
Stefan Gerber
Ranch Hand

Joined: Mar 08, 2008
Posts: 33
Thanks for your advice. It's seems to run when i place the jaxb-impl.jar into the endorsed folder. But i don't understand why i have to place the jaxb-impl.jar to the endorsed folder?
At http://jaxb.java.net/guide/Migrating_JAXB_2_0_applications_to_JavaSE_6.html is explicitly written that you should not endorse the jaxb-impl.jar
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42289
    
  64
It makes no sense to me that you should use the newer API classes with the older implementation classes, and -apparently- it doesn't actually work. I'm afraid you can't trust everything you read on the web :-)
Stefan Gerber
Ranch Hand

Joined: Mar 08, 2008
Posts: 33
yes, but i thought that they should know it because it's the reference reference implementation site... i agree it would be logical but than i have to place all jaxws jar (at least the ones that are located in the rt.jar) into the endoresed folder otherwise i can not be sure that all classes are taken from the new jar files.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java.lang.SecurityException: sealing violation