Re: SOAP encoded support

[Dan Diephouse]

Axis 2 does have experimental support for rpc-encoding. JAX-RPC support is a negative though. There really is no negative affect here - rpc-encoding is off by default. If anything this will improve the code because someone is actually looking at it and improving it. Also, there is a definite need for this. I've talked to several companies who have avoided using CXF because they can't also get their legacy services using it. Its a stumbling block for a lot of people who can't change their wsdls and want one framework to migrate them all. - Dan Glen Mazza wrote: I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for multiple years now--they refer their users to Axis1 for it. (Also, don't users who need this functionality rely on Axis1 xFire instead?) I can understand needing to retain obsolete technologies for backwards compatibility issues, but to retrofit CXF and have it now support an obsolete standard where it didn't before seems questionable. I'm not sure we should be supporting this deprecated technology, or providing an avenue for users to be working with it. Glen Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom: A couple of weeks ago I integrated CXF into OpenEJB for JaxWS support, and it went so well that it got me thinking that it would be great to use CXF for JaxRPC support as well. When I met Dan Kulp at ApacheCon, I mentioned this idea and he figured the biggest road block for implementing JaxRPC is supporting RPC/Encoded. So, last weekend I had some free time and decided to try to hack SOAP encoded support into CXF, and to my surprise it wasn't to difficult add Aegis Types to support the SOAP strut and reference classes. SOAP encoded struct support is provided by the StructType subclass of BeanType. I did have to extract a few methods from the writeObject method to hook element writing. I also had to make a couple of methods more public. As for how it works, the best place to start is the StructTypeTest. Basically, read and write follow the same pattern: 1) read/write message parts with the SoapRefType 2) read/write trailing serialized blocks with TrailingBlocks As each object is read we check if it contains a SOAP id attribute, and if it does we register it with the SoapRefRegistry in the context. If an element contains a SOAP ref attribute we register a ref that is "set" when the reference is resolved (which my be immediately or later). When writing, every complex object is given a SOAP id and every reference to another complex object is written as a reference. The actual referenced object registered with the MarshalRegistry in the context and is written by the TrailingBlocks class. I've attached my patch to (https://issues.apache.org/jira/browse/ CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays. WDYT? -dain -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com/blog