We have taken over several Java 6 webservices using Tomcat 6, in production at a customer site, which we’re attempting to upgrade to Java 11 and Tomcat 10
This software currently includes a custom XxxxxxWebActionServlet class, which extends from an old version of org.apache.struts.action.ActionServlet – this old version of struts ActionServlet currently used in production, and our current production XxxxxxWebActionServlet, both import javax.servlet.* classes
For Java 11 we have upgraded our XxxxxxWebActionServlet to import jakarta.servlet.* classes
Our upgrade results in the run-time ClassCastException shown below (from Tomcat 10’s localhost.yyyy-mm-dd.log)
Our guess is that this ClassCastException occurs because our upgraded XxxxxxWebActionServlet, which now imports jakarta.servlet., continues to extend the same older version of struts ActionServlet which imports javax.servlet. classes
After much web searching, we can’t seem to find a version of org.apache.struts.action.ActionServlet which imports jakarta.servlet.*
The last version of org.apache.struts.action.ActionServlet that we can find (in https://archive.apache.org/dist/struts/1.3.10) imports javax.servlet.* - ActionFormValidationInterceptor.java in struts-2.3.20.1 imports (but does not seem to use) org.apache.struts.action.ActionServlet, but ActionServlet.java itself does not seem to be present within struts-2.3.20.1/src
#1) Would a version of org.apache.struts.action.ActionServlet which imports jakarta.servlet.* exist somewhere else ?
#2) If not, we’d be very appreciative of any suggestions for how to circumvent this ClassCastException
Thanks very much in advance
22-Jun-2022 11:29:26.084 INFO [main]
org.apache.catalina.core.ApplicationContext.log Marking servlet
[action] as unavailable 22-Jun-2022 11:29:26.084 SEVERE [main]
org.apache.catalina.core.StandardContext.loadOnStartup Servlet
[action] in web application [/xxware] threw load() exception
java.lang.ClassCastException: class
com.xxxxxx.ui.web.jspframework.XxxxxxWebActionServlet cannot be cast
to class jakarta.servlet.Servlet
(com.xxxxxx.ui.web.jspframework.XxxxxxWebActionServlet is in unnamed
module of loader org.apache.catalina.loader.ParallelWebappClassLoader
#3ce3b176; jakarta.servlet.Servlet is in unnamed module of loader
java.net.URLClassLoader #6ddf90b0) at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1071)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1011)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4906)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5213)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1027)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:2001)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:828)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:478)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1708)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:320)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
at
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:886)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:795)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
If you're still on struts 1.x, split your upgrade into multiple steps:
Upgrade to a currently supported version of Tomcat
Upgrade your Struts code to a currently supported version (or framework)
There's no need to go to Tomcat 10 and the jakarta.servlet-world. Simply upgrade to Tomcat 9. Struts 1.x is from a time that jakarta.servlet was unheard of. So you won't find them together.
When you get your current code running on Tomcat 9, examine Struts' applicability and supported versions - consider upgrading (or consider picking a different framework). You can go live with your updated version long before that (e.g. just when everything works on Tomcat 9)
I'm currently working to upgrade struts1 (currently JakartaEE 8) and I think I'll reach JakartaEE 9-compatility next week (till 25. Nov. 2022).
In meantime take a look at my struts1-github-project to follow the progress: Weblegacy/Struts1
Greetings
Stefan
Related
I've been running a Ktor server application locally and deploying to Heroku for the last several months without any issues. However after deploying the latest version, I started to see the following error on any POST requests trying to process the request body on Heroku:
java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at io.ktor.utils.io.ExceptionUtilsJvmKt$createConstructor$$inlined$safeCtor$3.invoke(ExceptionUtilsJvm.kt:103)
at io.ktor.utils.io.ExceptionUtilsJvmKt$createConstructor$$inlined$safeCtor$3.invoke(ExceptionUtilsJvm.kt:90)
at io.ktor.utils.io.ExceptionUtilsJvmKt.tryCopyException(ExceptionUtilsJvm.kt:66)
at io.ktor.utils.io.ByteBufferChannelKt.rethrowClosed(ByteBufferChannel.kt:2456)
at io.ktor.utils.io.ByteBufferChannelKt.access$rethrowClosed(ByteBufferChannel.kt:1)
at io.ktor.utils.io.ByteBufferChannel.readRemaining$suspendImpl(ByteBufferChannel.kt:2126)
at io.ktor.utils.io.ByteBufferChannel.readRemaining(ByteBufferChannel.kt)
at io.ktor.utils.io.ByteReadChannelKt.readRemaining(ByteReadChannel.kt:217)
at io.ktor.serialization.SerializationConverter.convertForReceive(SerializationConverter.kt:158)
at io.ktor.features.ContentNegotiation$Feature$install$3.invokeSuspend(ContentNegotiation.kt:224)
at io.ktor.features.ContentNegotiation$Feature$install$3.invoke(ContentNegotiation.kt)
at io.ktor.features.ContentNegotiation$Feature$install$3.invoke(ContentNegotiation.kt)
at io.ktor.util.pipeline.SuspendFunctionGun.loop(SuspendFunctionGun.kt:248)
at io.ktor.util.pipeline.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:116)
at io.ktor.util.pipeline.SuspendFunctionGun.execute(SuspendFunctionGun.kt:136)
at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:78)
at io.ktor.request.ApplicationReceiveFunctionsKt.receive(ApplicationReceiveFunctions.kt:116)
at io.ktor.request.ApplicationReceiveFunctionsKt.receiveOrNull(ApplicationReceiveFunctions.kt:135)
Thinking that there might be something unexpected with the request body, I first tried changing call.receive<MyObject>() to call.receiveOrNull<MyObject>(), yet the issue persisted.
I got tipped off that this might be a JVM mismatch issues, so I checked Heroku's Java documentation and learned that the default JVM is 1.8. I then ran my application locally with Java 1.8 and was able to re-create the same behavior.
After changing the target JVM on Heroku for my application to version 11, this has apparently fixed the problem. While I did recently add the Ktor Authentication "feature", I can't see any other changes that might have caused this. I tried to find in the Ktor documentation what the minimum required JVM target is and was not able to find it. It's great that it's working again, but I'd like to have more confidence moving forward.
In order to ensure proper execution of the server and to avoid this kind of issue in the future, I'd like to ask what the supported JVM target(s) are for Ktor Server (and if possible, have this added to the Ktor documentation).
I solved by upgrding to ktor_version:1.6.7.
I'm porting a desktop JavaFx Application that requires Jackson to GluonMobile, it's my first time using this platform and I end up on the next stacktrace with a NoClassDefFoundError.
I would like to know if this requires a feature not supported by GluonMobile or if I just forgot to include something properly.
Apr 19, 2018 8:25:02 PM com.fasterxml.jackson.databind.ext.Java7Support <clinit>
WARNING: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added
[WARN] java.lang.Class: Class.forName() failed to load 'javax.servlet.Servlet'. Use the -forcelinkclasses command line option or add <forceLinkClasses><pattern>javax.servlet.Servlet</pattern></forceLinkClasses> to your robovm.xml file to link it in.
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...
TRACE Task Catching
java.lang.NoClassDefFoundError: java.util.function.ToLongFunction
at java.lang.VMClassLoader.findClassInClasspathForLoader(Native Method)
at java.lang.PathClassLoader.findClass(PathClassLoader.java:193)
at java.lang.ClassLoader.loadClass(ClassLoader.java:515)
at java.lang.ClassLoader.loadClass(ClassLoader.java:475)
at com.fasterxml.jackson.datatype.jsr310.ser.InstantSerializer.<init>(InstantSerializer.java:38)
at com.fasterxml.jackson.datatype.jsr310.ser.InstantSerializer.<clinit>(InstantSerializer.java:35)
at com.fasterxml.jackson.datatype.jsr310.JavaTimeModule.<init>(JavaTimeModule.java:161)
at com.general.plugin.jackson.json.JacksonObjectMapper.<clinit>(JacksonObjectMapper.java:214)
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:218)
at java.lang.Class.forName(Class.java:176)
at com.general.core.startup.Configuration.getSharableInstance(Configuration.java:69)
at com.general.core.startup.AbstractClient.<init>(AbstractClient.java:39)
at com.objectdb.core.startup.Client.<init>(Client.java:31)
at com.objectdb.ui.service.ClientFactory.getDBClient(ClientFactory.java:39)
at com.objectdb.ui.service.ClientTask.getDBClient(ClientTask.java:13)
at com.objectdb.ui.startup.Main$2.call(Main.java:30)
at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.lang.Thread.run(Thread.java:837)
This solution is quite a workaround that requires a bit of work.
Fixes Jackson 2.9.5 to work in gluon jfxmobile-plugin 1.3.10.
To fix jackson-databind to be able build immutable objects with a single constructor.
1.1 Drop the usage of the JDK8 module parameter-names since this requires a non implemented VM feature.
Use instead java.beans.ConstructorProperties.
1.2 Jackson uses for ConstructorProperties support some Interfaces from JDK8 that can be safety included as part of your project.
java.beans.ConstructorProperties
java.beans.Transient
1.3 Force link JDK7 support
forceLinkClasses = [
'com.fasterxml.jackson.databind.ext.Java7SupportImpl',
]
To fix jackson-datatype-jsr310.
2.1 It uses some JDK8 interfaces that can be safety included in your project.
java.util.function.ToIntFunction
java.util.function.ToLongFunction
2.2 It uses some JDK8 methods that can be safety substituted by JDK6-7 implementations, simply include in your project the java files and look up the pre-JDK8 back ports of the Time API.
JavaTimeModule.java
SerializerToPach.java
3.3 Point your own JavaTimeModule to your own serializer.
3.4 Register in your ObjectMapper your own JavaTimeModule.
Voila, now you can use the lattest Jackson to create immutable objects and use JDK8 Time classes in gluon jfxmobile-plugin 1.x
I'm trying to use Hibernate-Search in one of my JavaEE projects and seem to run into the exact same problem as described by Rallenaldo:
My Maven-project is using
Java JDK 1.8.0_73
Hibernate 5.0.6.Final
Hibernate-Search 5.5.2.Final (which uses Lucene 5.3.1)
and try to deploy on a Glassfish 4.1.1 application server (with just minimal changes to the standard configuration).
When deploying my application the deployment process ends in the following ClassCastException, when Lucene tries to load codecs from the package lucene-backward-codecs (version 5.3.1):
java.lang.ClassCastException: class org.apache.lucene.codecs.lucene40.Lucene40PostingsFormat
at java.lang.Class.asSubclass(Class.java:3404)
at org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:141)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:65)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
at org.apache.lucene.codecs.PostingsFormat$Holder.<clinit>(PostingsFormat.java:49)
at org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:112)
at org.apache.lucene.codecs.lucene40.Lucene40Codec.<init>(Lucene40Codec.java:115)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.lang.Class.newInstance(Class.java:442)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:45)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
at org.apache.lucene.codecs.Codec$Holder.<clinit>(Codec.java:47)
at org.apache.lucene.codecs.Codec.forName(Codec.java:113)
at org.apache.lucene.index.SegmentInfos.readCodec(SegmentInfos.java:469)
...
As has been elsewhere suggested, I have already verified that on my computer there is no other version of Lucene nor Hibernate-Search.
If I exclude the lucene-backward-codecs dependecy from the Maven-project, I get a similar ClassCastException at the exact same location in the Lucene-code:
java.lang.ClassCastException: class org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat
at java.lang.Class.asSubclass(Class.java:3404)
at org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:141)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:65)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
at org.apache.lucene.codecs.PostingsFormat$Holder.<clinit>(PostingsFormat.java:49)
at org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:112)
at org.apache.lucene.codecs.lucene53.Lucene53Codec.<init>(Lucene53Codec.java:160)
at org.apache.lucene.codecs.lucene53.Lucene53Codec.<init>(Lucene53Codec.java:80)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
...
I was not able to find a solution to this problem. And I am aware that Rallenaldo's question is actally also still open. Does someone know what causes this problem? Is this a Glassfish 4.1.1 problem?
Edit: I want to add the following observation to my original post: part of my project generates an standalone application packed as a self executable jar-file with the identical hibernate and lucene related dependencies, where I also use an entity manager with essentially the same configuration for the presistence context. In this case I do not have the above problem with hibernate-search. It starts without any problem and I can see it generate the expected index files. Here are the relevant lines from the persistence.xml:
<persistence-unit name="puName" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
<properties>
...
<property name="hibernate.search.default.directory_provider" value="filesystem"/>
<property name="hibernate.search.default.indexBase" value="/path/to/lucene/indexes"/>
...
</properties>
</persistence-unit>
Ok. Here is better answer. The solution (workaround) for us was to put lucene-analyzers-common-5.3.1.jar and lucene-core-5.3.1.jar directly into domain lib folder. After debugging I have found that class Lucene40PostingsFormat is being loaded by two classloaders and then instantiated from first classloader as a subclass of another (it gives class cast exception). I assume there is one unnecessary loading but I do not know why and how to change it with configuration only.
i have written a example for login using gwt tool with hibernate and spring integration.
getting this error-
Initializing App Engine server
SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6]
SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
Module setup completed in 579 ms
java.lang.AbstractMethodError: org.slf4j.impl.Log4jLoggerAdapter.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V
at org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:620)
at org.eclipse.jetty.util.log.JettyAwareLogger.debug(JettyAwareLogger.java:206)
at org.eclipse.jetty.util.log.Slf4jLog.debug(Slf4jLog.java:89)
at org.eclipse.jetty.util.component.Container.add(Container.java:206)
at org.eclipse.jetty.util.component.Container.update(Container.java:169)
at org.eclipse.jetty.util.component.Container.update(Container.java:111)
at org.eclipse.jetty.server.Server.setConnectors(Server.java:200)
at org.eclipse.jetty.server.Server.addConnector(Server.java:174)
at com.google.gwt.dev.codeserver.WebServer.start(WebServer.java:117)
at com.google.gwt.dev.codeserver.CodeServer.start(CodeServer.java:101)
at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:71)
at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.google.gwt.dev.shell.SuperDevListener$1.run(SuperDevListener.java:112)
jars i have used these jars---------
thanks in advance
AbstractMethodError can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.
Seems like the slf4j-api version you have is higher than the slf4j binding version (such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework).
For example - slf4j-api 1.7.6 along with slf4j-log4j12-1.5.8 will throw the same error.
You would need to syn the version of both slf4j apis and its binding jar verson.
Mostly its a libraries confilict, what that means there is a library uses log4j with version 1.5.8, and you have imported log4j 1.6.
2 things to try:
1- remove the log4j 1.6 from your imported jars.
2- replace log4j 1.6 jar file with log4j 1.5.8 jar file.
Hope that will help :)
I created a web-service app based on Apache CXF (2.7.5), deployed it on a Glassfish 3.0.1 and it works fine till I turn on WS-Sec support. Then I get the following exception when I try to do a web-service request:
Caused by: javax.xml.crypto.NoSuchMechanismException: class configured for XMLSignatureFactory(provider: ApacheXMLDSig)cannot be found.
at javax.xml.crypto.dsig.XMLDSigSecurity.doGetImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at org.apache.ws.security.message.WSSecSignature.init(WSSecSignature.java:127) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.ws.security.message.WSSecSignature.<init>(WSSecSignature.java:120) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1730) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:546) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:147) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
... 273 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) ~[felix.jar:na]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_43]
It seems that CXF invokes the XMLSignatureFactory class contained by Glassfish's default webservice provider implementation instead of invoking it's own one (it's in the xmlsec.jar file). All CXF files are packed into my war file and also have the <class-loader delegate="false" /> set in sun-web.xml.
Can someone help me why the Glassfish classloader works this way and how could I fix this?
I managed to find out that Glassfish (at least the 3.0.1 version) modifies the default class loading behavior to "protect" some packages (mostly javax. packages) in it's classpath. That's the reason why it finds and uses classes in it's modules directory instead of the one in my war's lib.
To solve this a JVM option should be added to the domain.xml:
<jvm-options>-Dcom.sun.enterprise.overrideablejavaxpackages=javax.xml.crypto,javax.xml.crypto.dsig</jvm-options>
With this Glassfish will allow to use your libs in your war file. But even with this setting it's problematic to use CXF with WS-Securityy along with Metro. The better solution is to use a Glassfish with only Web Profile not Full Profile as Web Profile doesn't have Metro included.