[Axiom] Proposal to make OMNode.build() delegate to it's children

[Thilina Gunarathne <cs...@gmail.com>]

Hi all,
It seems the current build() method in OMNodeImpl directly calls the
builder.next() repetitively till the tree is fully build for that
node. This behaviour works fine for all the cases except for the MTOM
optimised OMText objects. As you all aware AXIOM does not read the
actual binary when creating an OMText by the builder for a
XOP:Include. Actual binary attachment still remains in the stream till
the OMText.getDataHandler() is called. Because of this by simply
calling builder.next() from the OMNodeImpl will not build the whole OM
tree. This issue is captured in
https://issues.apache.org/jira/browse/WSCOMMONS-52.

My first proposal is to delegate the above OMNode.build() to all of
it's children. In this case We need by override this build() method in
 the OMElementImpl and in the OMText(). OMText.build() will call the
getDataHandler() method when  doing a build for a binary OMText node.
In OMElementImpl we can use the getFirstChild(0 and getextOMSibling()
to implement this.

Further if we need more flexibility, we can introduce a buildAll()
method with above logic and keep the build() intact. So the build()
will build OM without binary parts. buildAll() will build the full OM
with binary parts.

Any suggestions??

Thanks,
~Thilina






-- 
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
http://www.bloglines.com/blog/Thilina

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org

Re: [Axiom] Proposal to make OMNode.build() delegate to it's children

[Eran Chinthaka <ch...@opensource.lk>]

Thilina Gunarathne wrote:
> Hi all,
> It seems the current build() method in OMNodeImpl directly calls the
> builder.next() repetitively till the tree is fully build for that
> node. This behaviour works fine for all the cases except for the MTOM
> optimised OMText objects. As you all aware AXIOM does not read the
> actual binary when creating an OMText by the builder for a
> XOP:Include. Actual binary attachment still remains in the stream till
> the OMText.getDataHandler() is called. Because of this by simply
> calling builder.next() from the OMNodeImpl will not build the whole OM
> tree. This issue is captured in
> https://issues.apache.org/jira/browse/WSCOMMONS-52.
> 
> My first proposal is to delegate the above OMNode.build() to all of
> it's children. In this case We need by override this build() method in
> the OMElementImpl and in the OMText(). OMText.build() will call the
> getDataHandler() method when  doing a build for a binary OMText node.
> In OMElementImpl we can use the getFirstChild(0 and getextOMSibling()
> to implement this.
> 
> Further if we need more flexibility, we can introduce a buildAll()
> method with above logic and keep the build() intact. So the build()
> will build OM without binary parts. buildAll() will build the full OM
> with binary parts.


Thilina,

I prefer the second option. The simple reason is this. If you have an
OMElement and when you call the build method, if this OMElement is not
done, then there are no children for you to call the  build method of
those children.
Then what you can do is, ask the parser to proceed until done = true of
this element and then call the build method of all the children. This
is, IIUC, the second option.

So +1 to have two different methods.

-- Chinthaka

P.S. : Sorry for the late reply as I didn't see this email earlier.