Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 31 Oct 2005 16:56:05 -0800
From: Eric Johnson <eric@tibco.com>
Subject: Re: [Axis2] Data Binding
In-reply-to: <43618338.9030009@opensource.lk>
To: axis-dev@ws.apache.org
Message-id: <4366BD25.4060700@tibco.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051014)
References: <43604BC6.7040808@opensource.lk> <4360CDEA.2000309@apache.org>
 <43618338.9030009@opensource.lk>

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.

>  
>