axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: [Axis2] Implementing unwrapped (was Re: [Axis2] Planning for Axis2 next rev - 1.1 (?))
Date Fri, 23 Jun 2006 10:03:11 GMT
Hi Ajith,

Thanks for giving us some insights into your changes. Comments inline.

Ajith Ranabahu wrote:
>
>> I've been doing some more work on the JiBX version of this, mainly
>> working on the message receiver side. One approach that would let us
>> keep the current method-based code generation for the data binding
>> templates is to just have the invokeBusinessLogic() method generated by
>> the message receiver template call a method based on the operation name
>> to handle the actual business logic call. We could add a per-operation
>> flag for the data binding extension to indicate whether it wants to
>> handle the operation in this manner, as opposed to the current approach.
>
> Hmm... this is not really strightforward. You would not need to know
> whether there are two levels of skeletons and it seems slightly
> confusing even to implement.
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.
>
>> ...
>
> let me describe what I've done so far.
> There is a codegen extension called schemaUnwrappingExtension that
> looks at the elements refered by the messages and tries to find what
> are the parameters involved. The original schemas never change but the
> information found is added to a special container and hanged at the
> relevant AxisMessage. I've done this part and slightly modified the
> emitter also.
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.
> When it comes to the databinders, the extra task they have to do is to
> populate the typemap for the references of  the  unwrapped parts.
> Certain databinders like XMLBeans has no problem in this since it
> generates classes for all the element references, even for the
> internal ones. I can modify ADB to do this and I suppose jibX can also
> do a similar thing.
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?
> Once the databinders are done the templates need to change to
> concatanate the multiple arguments (or to expand them). This need to
> be incorporated into the templates properly and code should be
> generated to concatenate the arguments and build a single OMElement as
> required (or the other way). Note that this code is databinding
> specific and needs to go inisde the databinding templates.
> What I think is that we can find a failry generic method for
> unwrapping just like what we did for multiple databindings.
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 the 
XSLT code generation would be much simpler if there's a separate method 
to handle this for each operation.

  - Dennis

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message