Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

java.lang.SecurityException: sealing violation

 
Stefan Gerber
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jason Casey
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make sure you endorse all the JAXB libraries as well.
 
Stefan Gerber
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic