Axiom
  1. Axiom
  2. AXIOM-255

The sequence of events produced by OMStAXWrapper for XOP:Include is inconsistent

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.8
    • Fix Version/s: 1.2.9
    • Component/s: None
    • Labels:
      None

      Description

      For an Axiom tree built by MTOMStAXSOAPModelBuilder (or XOPAwareStAXOMBuilder) the sequence of events produced by OMStAXWrapper (i.e. the reader returned by getXMLStreamReader and getXMLStreamReaderWithoutCaching) for an XOP:Include element in the underlying stream depends on the state of the tree and on whether caching is enabled or not:

      Scenario 1: The tree has already been built. In this case OMStAXWrapper produces a CHARACTER event on which the OMConstants.DATA_HANDLER property can be queried. This is true both for caching enabled and disabled.

      Scenario 2: The tree has not been built and caching is enabled. In this case OMStAXWrapper produces an invalid sequence of events: namely, there is a spurious END_DOCUMENT event. Except for this bug, in this case OMStAXWrapper behaves as described in scenario 1.

      Scenario 3: The tree has not been built and caching is disabled. In this case OMStAXWrapper delegates to the raw StAX stream and produces START_ELEMENT and END_ELEMENT events for the XOP:Include element, leaving it up to the client code to decode XOP.

      Conclusion:

      • When caching is disabled, the sequence of events depends on the state of the tree (built or not).
      • The sequence of events produced by getXMLStreamReader and getXMLStreamReaderWithoutCaching is not the same.

      Since aspects such as caching and the state of the tree should be transparent to the client code, Axiom should be fixed so that OMStAXWrapper produces the same sequence of events in all cases. The correct sequence is the one described in scenario 1, because it is Axiom's responsibility to decode XOP.

        Issue Links

          Activity

          Hide
          Hudson added a comment -

          Integrated in ws-axiom-trunk #725 (See https://builds.apache.org/job/ws-axiom-trunk/725/)
          Removed some code that has become obsolete with the changes in AXIOM-255 and AXIOM-335.

          veithen :
          Files :

          • /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/om/impl/dom/TextNodeImpl.java
          • /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/om/impl/llom/OMTextImpl.java
          Show
          Hudson added a comment - Integrated in ws-axiom-trunk #725 (See https://builds.apache.org/job/ws-axiom-trunk/725/ ) Removed some code that has become obsolete with the changes in AXIOM-255 and AXIOM-335 . veithen : Files : /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/om/impl/dom/TextNodeImpl.java /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/om/impl/llom/OMTextImpl.java
          Hide
          Hudson added a comment -

          Integrated in ws-axiom-trunk #618 (See https://builds.apache.org/job/ws-axiom-trunk/618/)
          Removed a temporary workaround for AXIOM-255 that is no longer necessary since that issue is solved.

          veithen :
          Files :

          • /webservices/commons/trunk/modules/axiom/modules/axiom-common-impl/src/main/java/org/apache/axiom/om/impl/common/OMStAXWrapper.java
          • /webservices/commons/trunk/modules/axiom/modules/axiom-common-impl/src/main/java/org/apache/axiom/om/impl/common/SwitchingWrapper.java
          Show
          Hudson added a comment - Integrated in ws-axiom-trunk #618 (See https://builds.apache.org/job/ws-axiom-trunk/618/ ) Removed a temporary workaround for AXIOM-255 that is no longer necessary since that issue is solved. veithen : Files : /webservices/commons/trunk/modules/axiom/modules/axiom-common-impl/src/main/java/org/apache/axiom/om/impl/common/OMStAXWrapper.java /webservices/commons/trunk/modules/axiom/modules/axiom-common-impl/src/main/java/org/apache/axiom/om/impl/common/SwitchingWrapper.java
          Hide
          Hudson added a comment -

          Integrated in ws-axiom-trunk #540 (See https://builds.apache.org/job/ws-axiom-trunk/540/)
          AXIOM-240: Reverted part of r688927: XOP no longer requires special attention since AXIOM-255 and AXIOM-335 have been fixed.

          veithen :
          Files :

          • /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/om/impl/llom/OMElementImpl.java
          Show
          Hudson added a comment - Integrated in ws-axiom-trunk #540 (See https://builds.apache.org/job/ws-axiom-trunk/540/ ) AXIOM-240 : Reverted part of r688927: XOP no longer requires special attention since AXIOM-255 and AXIOM-335 have been fixed. veithen : Files : /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/om/impl/llom/OMElementImpl.java
          Andreas Veithen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Jeff Turner made changes -
          Affects Version/s Axiom 1.2.8 [ 12315531 ]
          Fix Version/s Axiom 1.2.9 [ 12315532 ]
          Andreas Veithen made changes -
          Project WS-Commons [ 12310250 ] Axiom [ 12311190 ]
          Key WSCOMMONS-485 AXIOM-255
          Affects Version/s Axiom 1.2.8 [ 12313556 ]
          Component/s AXIOM [ 12310703 ]
          Fix Version/s Axiom 1.2.9 [ 12313561 ]
          Andreas Veithen made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s Axiom 1.2.9 [ 12313561 ]
          Resolution Fixed [ 1 ]
          Hide
          Andreas Veithen added a comment -

          Fixed the issue as described in the previous comment.

          Show
          Andreas Veithen added a comment - Fixed the issue as described in the previous comment.
          Andreas Veithen made changes -
          Link This issue is blocked by WSCOMMONS-446 [ WSCOMMONS-446 ]
          Andreas Veithen made changes -
          Link This issue is blocked by WSCOMMONS-488 [ WSCOMMONS-488 ]
          Andreas Veithen made changes -
          Link This issue is blocked by WSCOMMONS-487 [ WSCOMMONS-487 ]
          Hide
          Andreas Veithen added a comment -

          Proposed solution:

          Currently, XOP:Include is decoded by MTOMStAXSOAPModelBuilder or XOPAwareStAXOMBuilder (the code is duplicated in both classes). Instead of this, create an XMLStreamReader wrapper that does the XOP decoding. It would use the IS_DATA_HANDLERS_AWARE extension so that the builder can retrieve the DataHandler objects. This wrapper would sit between the underlying parser and StAXOMBuilder (which already supports the IS_DATA_HANDLERS_AWARE extension). When caching is disabled (and the tree has not been built), OMStAXWrapper would then delegate to this wrapper instead of the underlying parser. This would solve the issue in scenario 3. Probably the issue in scenario 2 would also go away. In addition, this approach makes sure that there is one and only one piece of code responsible for XOP decoding.

          There are however two obstacles with this approach:

          • MTOMStAXSOAPModelBuilder and XOPAwareStAXOMBuilder support deferred loading of the DataHandler and this feature must be preserved. On the other hand, the IS_DATA_HANDLERS_AWARE extension doesn't allow deferred loading of the DataHandler. => need to implement WSCOMMONS-487 first
          • The fact that OMStAXWrapper would get an XOP decoded stream from StAXOMBuilder would aggravate the issue described in WSCOMMONS-488. => needs to be fixed first
          Show
          Andreas Veithen added a comment - Proposed solution: Currently, XOP:Include is decoded by MTOMStAXSOAPModelBuilder or XOPAwareStAXOMBuilder (the code is duplicated in both classes). Instead of this, create an XMLStreamReader wrapper that does the XOP decoding. It would use the IS_DATA_HANDLERS_AWARE extension so that the builder can retrieve the DataHandler objects. This wrapper would sit between the underlying parser and StAXOMBuilder (which already supports the IS_DATA_HANDLERS_AWARE extension). When caching is disabled (and the tree has not been built), OMStAXWrapper would then delegate to this wrapper instead of the underlying parser. This would solve the issue in scenario 3. Probably the issue in scenario 2 would also go away. In addition, this approach makes sure that there is one and only one piece of code responsible for XOP decoding. There are however two obstacles with this approach: MTOMStAXSOAPModelBuilder and XOPAwareStAXOMBuilder support deferred loading of the DataHandler and this feature must be preserved. On the other hand, the IS_DATA_HANDLERS_AWARE extension doesn't allow deferred loading of the DataHandler. => need to implement WSCOMMONS-487 first The fact that OMStAXWrapper would get an XOP decoded stream from StAXOMBuilder would aggravate the issue described in WSCOMMONS-488 . => needs to be fixed first
          Andreas Veithen made changes -
          Assignee Andreas Veithen [ veithen ]
          Andreas Veithen made changes -
          Field Original Value New Value
          Link This issue is related to AXIS2-4363 [ AXIS2-4363 ]
          Andreas Veithen created issue -

            People

            • Assignee:
              Andreas Veithen
              Reporter:
              Andreas Veithen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development