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] Extending databinding code generation
Date Mon, 08 May 2006 00:11:39 GMT
After looking at this in more detail my inclination is to extend the 
existing TypeMapping schema used by the code generation so that it can 
carry information for the data binding frameworks. Right now the type 
mapping goes from an element qname (which I believe is always the 
element referenced by a message part) to a Java class name. That's fine 
for plain doc/lit, but for wrapped we need better granularity. Just as 
one example, the same element name can be used for different purposes 
and even different types of values within different wrapped operations. 
That means context information is needed, so that the data binding 
framework knows when it's generating code for a foo(user, password) call 
as opposed to a bar(user, amount, items) call.

My thought is to allow the value of a type mapping to be either the Java 
class name String, as now, or an org.w3c.dom.Element. If the Element 
value is seen, the code generation will know that the data binding 
framework wants to handle this message part directly, and will include 
the Element in the XML document passed to the XSLT, which in turn will 
invoke the data binding XSLT for the details of the handling. It'll be 
the responsibility of the data binding framework to generate code that 
constructs the argument list for the service method call in the message 
receiver, and that constructs the document from the arguments in the 
client stub.

Any comments?

  - Dennis

Dennis Sosnoski wrote:

> I've been looking into implementing unwrapping of method call 
> parameters for JiBX. The current code generation approach uses several 
> different XSLT templates, with some templates just generating generic 
> code for handling the service operations while the details of 
> conversions to and from XML are handled by toOm()/toEnvelope() and 
> fromOm() that are specific to the data binding approach being used. 
> For unwrapped handling I think we need to change the code generation 
> to use an in-line approach, where the data binding framework is 
> invoked to generate code that gets embedded directly within the 
> operation method on the client stub, or within the invokeBusinessLogic 
> method of the message receiver on the server. The reason I'm 
> suggesting this is because the current approach of calling other 
> methods gets very messy when you're passing or returning a list of 
> objects, rather than just a single object.
>
> I don't know how well this will fit with the current 
> org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter. 
> At a minimum, it's going to need to pass additional information in the 
> XML documents used to drive the code generation (since each data 
> binding framework will have it's own approach to handle unwrapping, 
> and will need to pass the appropriate information to its code 
> generation template). I can just start extending the current code to 
> support unwrapped with JiBX, but figured I'd bring it up for 
> discussion first to see if anyone else is working in this area.
>
> To enable unwrapping I assume we'll want a WSDL2Java flag, as in 
> Axis1. Each framework would be able to check this flag and then set 
> per-operation flags to control the code generation, selecting between 
> the current form (toOm()/toEnvelope() and fromOm()) and an unwrapped 
> approach. The AxisServiceBasedMultiLanguageEmitter would then use this 
> per-operation flag to control how that operation is generated.
>
>  - Dennis
>

Mime
View raw message