Mailing-List: contact commons-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: commons-dev@ws.apache.org
Message-ID: <79579879.1246913715128.JavaMail.jira@brutus>
Date: Mon, 6 Jul 2009 13:55:15 -0700 (PDT)
From: "Andreas Veithen (JIRA)" <jira@apache.org>
To: commons-dev@ws.apache.org
Subject: [jira] Created: (WSCOMMONS-488) The sequence of events produced by
 OMStAXWrapper with inlineMTOM=false is inconsistent
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

The sequence of events produced by OMStAXWrapper with inlineMTOM=false is inconsistent
--------------------------------------------------------------------------------------

                 Key: WSCOMMONS-488
                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-488
             Project: WS-Commons
          Issue Type: Bug
          Components: AXIOM
    Affects Versions: Axiom 1.2.8
            Reporter: Andreas Veithen
            Assignee: Andreas Veithen
            Priority: Minor


The inlineMTOM=false mode in OMStAXWrapper (introduced by WSCOMMONS-344) only works in a consistent way if the underlying StAX stream comes from an MTOM/XOP message, but not if the underlying stream uses the IS_DATA_HANDLERS_AWARE extension. Indeed:

- If the OMStAXWrapper is generating events from the Axiom tree (because caching is enabled or the tree has already been built), then the change in WSCOMMONS-344 makes sure that an XOP:Include element is returned for optimized binary content.
- On the other hand, if caching is disabled and the Axiom tree has not been built, OMStAXWrapper delegates to the underlying stream reader. If there is optimized binary content, it will be represented as a CHARACTERS event instead of an XOP:Include element (as in inlineMTOM=true mode).

Since this issue only occurs if inlineMTOM=false (which is not the default) and the underlying stream uses the IS_DATA_HANDLERS_AWARE extension (which is generally only the case for a stream coming from another Axiom tree or generated by a databinding framework), this issue is less serious than WSCOMMONS-485.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.