> I want to dig into the stack trace I am seeing > onthe server side before I answer that. It could be that the stack trace > is causing the response message to be garbled.
Well the NPE in VersionTransformer.convert() is related to the version mismatch. The CXF RM layer wants to unmarshall an incoming CreateSequence message containing an AcksTo element, which itself contains a wsa:EndpointReferenceType where the wsa namespace of the 2004/08 variety. Whereas the WCF client is sending a CreateSequence conatining an AcksTo of the 2005/08 vintage. So the unmarshalled AcksTo ends up being null, which causes VersionTransformer.convert() to blow up with the NPE. Now of course the VersionTransformer should be coded more defensively. But the underlying issue is still the version mismatch AFAICS. Cheers, Eoghan Eoghan Glynn wrote: > > Hi Bryan, > > CXF supports WS-RM 1.0, AKA 2005/02[1]. As you probably know, this is based > on the 2004/08 version of WS-A. > > In fact, the CXF support for multiple WS-A versions was added specifically to > facilitate WS-RM, whereas previously we supported only the then-current > 2005/08 version of WS-A. > > So currently we support WS-A 2005/08 natively throughout, and use this > version also by default on the wire. In addition, we provide a programmatic > mechanism to use 2004/08 as the "exposed" version of WS-A, i.e. the version > tranformed to before encoding in the outgoing payload (or transformed from > after decoding from the incoming payload). > > Now as things currently stand, the CXF WS-RM layer is hard-coded to set this > exposed WS-A version to 2004/08 (as required by the RM 1.0 spec). As Dan > mentioned earlier in this thread, we took part in an MS WS-* interop plugfest > in Redmond back in the summer of 2007. At that point WCF was perfectly happy > with WS-A 2004/08 alongside WS-RM 2005/02. In fact I just dug out the > reliable messaging test plan distributed to participants before the event, > and it explicitly calls for WS-A version 2004/08 to be used. > > Now obviously things have changed in the meantime with WCF. While I think WCF > is acting ultra-vires in this respect, in the interest of maximizing > interoperability, I guess we could allow CXF WS-RM to work around the issue, > by configurably falling back on WS-A 2005/08. Let me know if you would be > interested in such a work-around. > > Cheers, > Eoghan Thanks for the reply. I want to dig into the stack trace I am seeing onthe server side before I answer that. It could be that the stack trace is causing the response message to be garbled. Right now, I get the following on the server when a WCF client sends a message: 2009-03-12 08:51:55,066 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) java.lang.NullPointerException 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.ws.addressing.VersionTransformer.convert(VersionTransformer.java:137) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.ws.addressing.VersionTransformer.convert(VersionTransformer.java:248) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.ws.rm.Servant.createSequence(Servant.java:142) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.ws.rm.Servant.invoke(Servant.java:68) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92) 2009-03-12 08:51:55,067 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226) 2009-03-12 08:51:55,068 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89) 2009-03-12 08:51:55,068 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99) 2009-03-12 08:51:55,068 ERROR [STDERR] (http-hattrick.usersys.redhat.com%2F10.11.231.22-8080-1) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:305) -- bk
