Question

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?

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top