ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] [Resolved] (AXIOM-420) Support push-only OMDataSources
Date Thu, 16 Aug 2012 17:37:38 GMT


Andreas Veithen resolved AXIOM-420.

    Resolution: Fixed
> Support push-only OMDataSources
> -------------------------------
>                 Key: AXIOM-420
>                 URL:
>             Project: Axiom
>          Issue Type: Improvement
>          Components: API, LLOM
>    Affects Versions: 1.2.13
>            Reporter: Andreas Veithen
>            Assignee: Andreas Veithen
>             Fix For: 1.2.14
> The OMSourcedElement/OMDataSource feature assumes that a data source is equally well
capable of providing an XMLStreamReader and of serializing the data to an XMLStreamWriter.
However, this is often not the case: serializing to an XMLStreamWriter is in generally easy,
but constructing an XMLStreamReader may be highly non trivial. The consequence is that many
OMDataSource implementations implement getReader by first serializing the data to an intermediary
representation and than constructing an XMLStreamReader from that representation. The following
two approaches are used most often:
> 1. getReader serializes the data as XML to a byte array (using one of the serialize methods
defined by OMDataSource) and then returns an XMLStreamReader pull parser constructed from
that byte array. Note that this is highly inefficient (and even gives unexpected results)
if the serialization produces optimizable base64 binary data.
> 2. getReader first creates an Axiom tree and then uses OMContainer#getXMLStreamReader().
For example, ADB does this by using an XMLStreamWriter implementation (called MTOMAwareOMBuilder)
that constructs the Axiom tree. That XMLStreamWriter is passed to the serialize(XMLStreamWriter)
method. That approach is inefficient because in the worst case, the Axiom tree is built twice:
once by getReader and then again by OMSourcedElement. This should be considered as an anti-pattern
> The issue can be avoided if the implementation of OMSourcedElement is changed such that
for this type of OMDataSource it uses a different approach to expand the element: instead
of using a standard OM builder to expand the element, it would use the OMDataSource#serialize(XMLStreamWriter)
method together with an XMLStreamWriter that builds the nodes and adds them to the OMSourcedElement.
This is similar to what ADB already does, except that the tree would be built only once because
the constructed nodes are directly added to the OMSourcedElement. Of course, since this approach
is push based, deferred building will not work and the OMSourcedElement is always built completely
if it gets expanded. It is nevertheless better than the other approaches currently in use.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message