java.lang.NoSuchMethodError: org.apache.ws.security.WSDataRef.getTransformA

[padams]

Starting a new thread as this is really a new/separate problem.

I'm running 4.4.1-fuse-03-06.

I'm attempting to interact with an external service that's secured by SAML SV.  My original issue was a version dependency missmatch between the installed version of wss4j and joda-time which required an update:

FUSE_ESB/system/org/apache/activemq/activemq-karaf/5.5.1-fuse-03-06/activemq-karaf-5.5.1-fuse-03-06-features.xml

change

mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.joda-time/1.5.2_2

to

mvn:joda-time/joda-time/1.6.2

Once I made this change my cxf client is able to round trip with the external SAML service but when processing the response I'm receiving the exception below.

On my previous thread there was some question about a version of WSS4J that was installed into my setup so to rule this out as a possible root of this problem I setup a clean new installation, made the one version change above and deployed my bundle to it and the same exception below happens.  Given the fact that the underlying error is a NoSuchMethodError this also strikes me as a version mismatch kind of problem though I'm not sure how to verify.

Any help greatly appreciated.

Thanks.

java.lang.NoSuchMethodError: org.apache.ws.security.WSDataRef.getTransformAlgorithms()Ljava/util/List;

at org.apache.cxf.ws.security.wss4j.policyvalidators.AlgorithmSuitePolicyValidator.checkDataRefs(AlgorithmSuitePolicyValidator.java:124)

at org.apache.cxf.ws.security.wss4j.policyvalidators.AlgorithmSuitePolicyValidator.checkSignatureAlgorithms(AlgorithmSuitePolicyValidator.java:96)

at org.apache.cxf.ws.security.wss4j.policyvalidators.AlgorithmSuitePolicyValidator.validatePolicy(AlgorithmSuitePolicyValidator.java:57)

at org.apache.cxf.ws.security.wss4j.policyvalidators.AbstractBindingPolicyValidator.checkProperties(AbstractBindingPolicyValidator.java:172)

at org.apache.cxf.ws.security.wss4j.policyvalidators.AsymmetricBindingPolicyValidator.validatePolicy(AsymmetricBindingPolicyValidator.java:76)

at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.checkBindingCoverage(PolicyBasedWSS4JInInterceptor.java:581)

at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.doResults(PolicyBasedWSS4JInInterceptor.java:468)

at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:265)

at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:85)

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)

at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:795)

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1626)

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1493)

at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1401)

at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)

at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:194)

at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)

at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:648)

at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)

at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)

at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:461)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:364)

at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)

at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)

at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)

Since it's a NoSuchMethodMethodError this also strikes me as some sort of version mis-match issue?

I'm running 4.4.1-03-06.

Thanks for the help.

[padams]

I verified that the missing method is in fact not in wss4j 1.6.1 and doesn't show up until wss4j 1.6.4

$ javap -classpath wss4j-1.6.4/lib/wss4j-1.6.4.jar org.apache.ws.security.WSDataRef | grep Transform

    public void setTransformAlgorithms(java.util.List);

    public java.util.List getTransformAlgorithms();

is this an issue with the cxf-bundle?

[ffang]

Hi,

Good catch,  as a workaround you can edit

./system/org/apache/camel/karaf/apache-camel/2.8.0-fuse-03-06/apache-camel-2.8.0-fuse-03-06-features.xml

and

./system/org/apache/servicemix/apache-servicemix/4.4.1-fuse-03-06/apache-servicemix-4.4.1-fuse-03-06-features.xml

change

then remove $FUSE_ESB/data folder and restart ESB, next release would fix it.

Thanks for reporting.

Freeman

[padams]

Thanks, it now works for me.

I did have one issue though.  In:

./system/org/apache/servicemix/apache-servicemix/4.4.1-fuse-03-06/apache-servicemix-4.4.1-fuse-03-06-features.xml

There are multiple references to wss4j, dependencies of cxf, servicemix-http and servicemix-jms.

In my use case I believe the only one that's currently important is the cxf dependency but at first I simply changed all three versions for 1.6.1 to 1.6.4.  And my bundle then failed to load.  I then toggled the dependency of servicemix-http back to 1.6.1 and it loaded.  To verify this was the issue I tried to set it back again to 1.6.4 and then my bundled failed to load but no exception was displayed.  I put a fresh copy (not re-compiled, essentially a touched version) into the deploy directory and then it loaded and functioned?  Each time I deleted the data directory after updating dependencies.

I lost the original exception in this process and now can't seem to recreate it which makes me nervous.

But things appear to be up and running.

Thanks again for the help.