axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ajith Ranabahu" <>
Subject Re: [Axis2] Implementing unwrapped (was Re: [Axis2] Planning for Axis2 next rev - 1.1 (?))
Date Mon, 26 Jun 2006 10:28:20 GMT
Hi Dennis,
Thanks for the quick response. Please see my comments in-line.
BTW I missed the long thread of mails during the weekend so sorry for
being late

> I don't see it as that complex. Basically there's just a flag for each
> operation set by the data binding extension, and if the flag is set the
> message receiver template skips generating the code to call the service
> method and instead calls the wrapper method (which is then generated by
> the data binding extension). This is essentially very similar to what is
> done currently with the toOM and fromOM method generation, but just
> letting the data binding handle the entire service method invocation.
> >

OK. I see the point. (and your argument about deser/ser-ialization
context seems very much valid too) So this wrapper(unwrapper) method
is generated inside the MessageReceiver / Stub ? if the user would not
see any specific difference in the artifacts then that would be fine.
But still we can generate a piece of common code so that the calling
of the toOM is generalized and there is only the absolutely necessary
code inside the databinding template.

> >

> I've said before how for the JiBX handling I really want to control the
> unwrapping in the data binding extension code, rather than use a generic
> approach. As long as it's still possible for me to do that and overwrite
> what's been done by the schemaUnwrappingExtension there shouldn't be any
> problem with me implementing my changes.

The issue here is figuring out the skeleton/stub method signature.
Even if the databinding handles the unwrapping of parameters we have
to generate the method sognatures right! To do this we need to know
the mapping at the time of generating code. What I suggest is to have
an extension that walks the schema and extracts these details and then
 attach this to the Axis tree for later use (the use would be from the
the emitter). For primitive cases the relevant codegen extension can
populate the type map relevantly and that should cover  the complete

> 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?

> I'm not sure I understand what you're saying here. The method-based
> approach that I outlined was intended to allow a single OMElement to be
> passed off and another returned, with all the details of translating
> that element and calling the service code handled by the data binding
> code generation. It sounds like you're talking about doing the same
> thing inline. That's the approach I started with, before deciding
> XSLT code generation would be much simpler if there's a separate method
> to handle this for each operation.

We are more or less talking about the same thing :) Only thing is we
need to find a solution that would cater for all.
>   - Dennis
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ajith Ranabahu

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message