Eran Chinthaka wrote:
Steve Loughran wrote:
On the subject of data binding, it would suit me nicely if you could
easily build an OMElement graph from a DOM or SAX tree.
I believe there is a "SAX" builder for AXIOM trees. I don't think there
is any test code for it, and having looked at the code, I suspect it
doesn't work right, at least not always. If you can find a DOM to SAX
adapter, then Axis is already almost there.
Maybe I don't understand your question either.
What do you mean here ? Are you asking for a special OMElement which
wraps any data binding object, as Dennis explained.
[snip]
BTW, you all agree that the only missing "feature" we should have in
Axis2, for it to be promoted for 1.0 status, is Axis2 own databinding
implementation. I think Ajith has almost completed XMLBeans integration.
So lets have a broader discussion on this.
One of the concerns raised in the last chat is the integration of data
bound object to OM.
So as I see there are two ways;
1. Getting pull parser from the data bound object, irrespective of which
framework was used to data bound, and create an OMElement out of it and
hangs that to the OM tree.
DataBoundObject dbObj = // get the data bound object
OMElement dbObjWrapper = new
StaxOMBuilder(dataBoundObject.getPullParser()).getDocumentElement();
// add this to body of wherever you want
body.addChild(dbObjWrapper);
2. Giving the data bound object an XSR (XMLStreamWriter) and ask him to
serialize himself
DataBoundObject dbObj = // get the data bound object
SpecialOMElement dbObjContainer = new SpecialOMElement(dbObj);
dbObjContainer.serialize(xmlStreamWriter);
(are there other approaches ? if so please comment)
Perhaps yes, there are other approaches. Or maybe this is what you're
getting at with your second proposal here? How about setting it up so
that serialization is (normally) done externally to the object itself.
That implies that the "data bound object", as you refer to it, has Java
Bean semantics, or some such, in that there would need to be "getters"
for every property that might be serialized (or package protected members).
The fundamental point, though, is that a bean need not have its own
serialization code - it can be "dumb" to how it actually gets
serialized. If you take that approach, the above question as to whether
you're using a "writer" or a "reader" might be moot. The generated(?)
serialization code can share gobs of functionality and perhaps do both.
I personally prefer the first approach as it seems cleaner for me. Its
the same thing we do to connect data in to OMElement. And it nicely and
elegantly fit in to the differed building approach. This approach is
almost implemented for ADB (Axis2 Data Binding).
Well the problem in that approach is that (thanks to Dennis for
pointing), JAXB, JiXB do not have a way of getting a pull parser. But
they do have a way of doing the second method.
I still like an approach that uses a "writer", rather than a "reader" to
generate the XML. Two particular reasons come to mind:
* If the point is deferred creation of the XML, that probably also
means deferred reading of the state to be return in a response.
In other words, if data object "X" is returned in a SOAP response,
by the time all the headers are wrapped around it, and "X" is
actually turned into XML bytes to be streamed back to the client,
"X" might actually have changed, and the values written to XML
might be different than those at the time that the service
returned from its execution. Even with copious documentation, I
can imagine poor developers being surprised by some obscure race
condition around the deferred writing.
* It will be easier to debug obscure serialization bugs if the
serialization state is kept on the stack and in the order of the
code, rather than in state variables that change with each call to
get the next token.
-Eric.
