Ok; I can confirm it works correctly with tomcat 7 as well, at least as executed through the cargo maven2 plugin. Still fails in the latest Jetty M3 version.
Ross On Wed, Jun 1, 2011 at 10:32 AM, Daniel Kulp <[email protected]> wrote: > > > 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 >
