Dennis Sosnoski wrote:
Hi Ajith,
Sounds great on the data binding support! I'll check it out within the
next couple of weeks. JiBX currently uses XMLPull for input, but I can
probably implement a simple wrapper for converting between the Axis
StAX parser and an XMLPull API. Are you listening,
that should be very easy - those two APIs are very similar (XmlPull is
just much smaller providing all functionality in two interfaces and one
factory ...)
Alek - any comments?
around but just insanely busy :)
The output may be a little tougher, since that's oriented toward
writing directly to a stream through a custom interface; it may
require some post-1.0 tweaks to JiBX, but shouldn't present any major
problems.
i am much more concerned with supporting multiple data binding models
and flexible pipeline to allow databinding of parts of XML message or
not binding for parts of it at all (for example binding some header but
not binding parts of SOAP body or binding it efficiently into int[] and
bypassing XmlBeans that is used for other parts ...)
best,
alek ("busy")
Ajith Ranabahu wrote:
Hello Dennis,
The internals of the Databinding framework are as follows
1. We have something called extensions that run before the actual
code generator. For XMLBeans we have an extension that takes the
Schema element from the WSDL file and feeds it into the XB schema
parser. The logic of XB is completely inside the XB extension. After
the XB code generation, a type mapper is populated with the generated
types and passed on to the Axis2 code generator.
2. The generated classes include something called the
DataBindSupporter. DataBindSupporter has 'toOM' and 'FromOM' methods
which accept either a generated object and or the omelement
respectively and does the necessary conversion. The databinding logic
is completely inside the databinding supporters.
So as you can see the codegenerator is completely based on the
strategy of passing a schema element and getting the type map. You can
customize it with minimum effort. In particular have a look at the
XMLBeansExtension.java class in the
org.apache.axis2.wsdl.codegen.extension package
As for the MTOM support we have not yet thought about it seriously (I
mean how it affects code generation :)). Since MTOM is solely a
transport time thingy (no description of it in the XSD or the WSDL) we
were thinking of a user switch in the tool that will generate a
slightly different bunch of code which optimizes the output.
On 7/14/05, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
I recently made some changes (going into JiBX RC1) to support using
JiBX
with SOAP. These are primarily designed around what I've found was
necessary for JibxSoap, but I'm also planning to hook into Axis2 and
the
same requirements are likely to apply there. I know the 0.9 version has
XmlBeans support in place - has anything been done yet to define a
general-purpose API usable with other data binding frameworks? I'm
interested both in runtime support and code generation (so that there's
a way for Axis to pass off a schema subset to be handled by the data
binding framework, along with any appropriate customization parameters
for the data binding code generation, and get back some sort of map
from
types to classes).
I'm also curious if anyone has considered how MTOM is going to work in
combination with data binding. It seems like there'll have to be some
way for the data binding framework to pass back information about the
blobs to be sent as attachments, and to access the attachments when
unmarshalling. In the case of JiBX I'm planning to add that in 1.1 with
an internal API that allows JiBX to communicate with whatever runs the
transport, then supply separate implementations of the transport
interface for different usages (JibxSoap, Axis2, etc.). That aspect of
MTOM has always seemed a bad smell to me, but since The Powers That Be
(AKA the W3C) have decided it's the wave of the future I'll do my best
to work with it.
- Dennis
--
The best way to predict the future is to invent it - Alan Kay
