cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <>
Subject Re: SOAP encoded support
Date Wed, 12 Dec 2007 13:59:48 GMT
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.


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 ( 
> CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> -dain

View raw message