cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: SOAP encoded support
Date Wed, 12 Dec 2007 14:58:08 GMT
Hmm. Well, I committed Dain's patch without predicting that there might
be some negative opinion.

I like the idea of CXF being a comprehensive tool. I reviewed Dain's
patches, and the negative impact of adding 'encoding' is far smaller
than the positive aspect of Dain's modularity improvements.

CXF's claim to fame to some significant extent is 'We build what you
need, not what we think you need.' 

Someone could, by the way, take a similiar attitude toward my JavaScript
project. Is JavaScript client generation a core function? Is it a good
idea, in part, because it gets us another committer and another smart
person working on whatever?



On Wed, 2007-12-12 at 09:31 -0500, Glen Mazza wrote:
> 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