cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@verizon.net>
Subject Re: SOAP encoded support
Date Wed, 12 Dec 2007 14:31:35 GMT
That's what Axis1 is for.  Besides, can't they also use XFire?  Or SAAJ?
Or Dispatch objects?  It can be done[1].

The Axis dev's have always been quite unyielding on this.  If you say
you need RPC/encoded on the axis-user ML, you're politely referred to
Axis1 and that's that.

I don't know the severity of the changes involved, or any long-term
consequences of supporting this.  My instinct is, though, that if you
need to play a record, you have to get a phonograph machine.  Asking CD
sound systems to retrofit seems unrealistic.

Glen

[1] http://www.jroller.com/gmazza/date/20071102

Am Mittwoch, den 12.12.2007, 09:08 -0500 schrieb Benson Margulies:
> Because there are, apparently, plenty of production systems that use it
> that folks want to talk to. And asking them to use Axis1 is in the
> category of 'putting out a stumbling block for the blind'.
> 
> 
> On Wed, 2007-12-12 at 08:59 -0500, 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
> > 
> 


Mime
View raw message