axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <>
Subject Re: [Axis2] Implementing unwrapped (was Re: [Axis2] Planning for Axis2 next rev - 1.1 (?))
Date Sat, 24 Jun 2006 23:28:42 GMT

The terminology is confusing.

When using Document style, the message body on the wire must always contain
at most one element. When using "non-wrapped" document style, the
databinding maps that body element to a value object. When using "wrapped"
style, that body element (which has the same name as the operation) is a
wrapper around a set of parameter elements. "Unwrapping" refers to the
process in which the databinding system automatically unwraps the body
element and maps the parameter elements to individual classes. Support for
"wrapped" style (which includes the ability to automatically "unwrap" the
body wrapper element) is what Ajith is currently implementing.


On 6/24/06, Dennis Sosnoski <> wrote:
> Sanjiva Weerawarana wrote:
> > On Fri, 2006-06-23 at 22:03 +1200, Dennis Sosnoski wrote:
> >
> > ...
> >
> >> One of the points of unwrapping is supposed to be to reduce the number
> >> of class generated. Besides, in many cases those unwrapped parts are
> >> going to be primitives. How do you plan to handle these?
> >>
> >
> > Reduce the # of classes? Unwrapping *increases* the number of classes ..
> > each arg becomes a separate class. I must be missing something.
> >
> I think that's the crux of where my approach differs from what Ajith is
> implementing. You're thinking in terms of a unique class per element
> name, which leads to an even worse proliferations of unnecessary classes
> than what we've got now. The reason I want to handle the entire call to
> the service method within the data binding-specific code is so that I
> can work with primitives and classes that have a defined structure
> binding (the equivalent of a complexType definition) but may be reused
> in different places with different names. That way you're working only
> with the actual data classes, without the wrapper classes.
> Here's a snippet from the Axis(1) users guide, describing the Axis(1)
> handling of wrapped vs. unwrapped:
> For a *document* style service, this would map to a method like this:
> public void method(PurchaseOrder po)
> In other words, the ENTIRE <PurchaseOrder> element would be handed to
> your method as a single bean with three fields inside it. On the other
> hand, for a *wrapped* style service, it would map to a method like this:
> public void purchaseOrder(String item, int quantity, String description)
> Note that in the "wrapped" case, the <PurchaseOrder> element is a
> "wrapper" (hence the name) which only serves to indicate the correct
> operation. The arguments to our method are what we find when we "unwrap"
> the outer element and take each of the inner ones as a parameter.
> This is what users expect from unwrapped support, not to have to deal
> with a whole new layer of classes wrapping the simple bean values.
>   - Dennis
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message