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
