Description
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 (see http://ws.apache.org/axiom/userguide/ch05.html#d5e679).
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.
Attachments
Issue Links
- relates to
-
AXIS2-4602 JAX-WS MTOM issue
-
- Reopened
-