This seems to be a problem specific to Jetty. I'm not sure what's happening with it yet. However, if I take the war and drop it into a "virgin" Tomcat 6 install, the "mvn exec:exec" in the client dir runs fine. Also if I run "mvn tomcat:run" in the service war and update the URL's in the client project to the new location (http://localhost:8080/service-war/services/doubleit) then it also runs fine. Thus, it does look like it's some sort of conflict with Jetty. I'm just not sure what yet.
Dan On Tuesday, May 31, 2011 7:41:08 PM Ross Lodge wrote: > I've been trying to get the new 2.4.0 release to work in a project that I'm > using that uses WS-Security and WS-SecurityPolicy in a WSDL-First SOAP > service, and I am getting a signature verification failure: > > Caused by: org.apache.ws.security.WSSecurityException: The signature or > > > decryption was invalid; nested exception is: > > > > org.apache.ws.security.WSSecurityException: The signature or decryption > > was invalid > > > > at > > org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(Si > > gnatureProcessor.java:378) ~[wss4j-1.6.0.jar:1.6.0] > > > > at > > org.apache.ws.security.processor.SignatureProcessor.handleToken(Signature > > Processor.java:174) ~[wss4j-1.6.0.jar:1.6.0] > > > > at > > org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityE > > ngine.java:396) ~[wss4j-1.6.0.jar:1.6.0] > > > > at > > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JIn > > Interceptor.java:248) ~[cxf-rt-ws-security-2.4.0.jar:2.4.0] > > > > ... 35 common frames omitted > > > > Caused by: org.apache.ws.security.WSSecurityException: The signature or > > decryption was invalid > > > > at > > org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(Si > > gnatureProcessor.java:375) ~[wss4j-1.6.0.jar:1.6.0] > > > > ... 38 common frames omitted > > It's quite possible that I'm missing something (e.g. relating to how WSS4J > 1.6 needs to be configured vs WSSJ 1.5, for instance), or this could be a > bug of some kind. > > Any help would be appreciated; I've uploaded sample code that exhibits this > problem to: > > http://software-entropy.com/wp-content/uploads/2011/05/ws-security-bug.2.3. > 4.zip > http://software-entropy.com/wp-content/uploads/2011/05/ws-security-bug.2.4 > .0.zip > > Both of these are simple maven projects based on Glen Mazza's blog-posts > about how to build a WS-Security-enabled service with CXF. You'll need to > do a "mvn clean install" from the parent module and then first a "mvn > jetty:run" (or deploy the war to your favorite container) in the > service-war module and, while it's running, a "mvn exec:exec" in the > client module. For me, this works fine for the 2.3.4 version of the code, > but fails for the 2.4.0 version of the code; everything aside from the CXF > dependency version is the same between the two zip files. > > Thanks. > > (yes, this is a repost, with a different and potentially easier-to-use > example; I've been unable to find a solution for this). > > Ross M. Lodge -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
