Axiom
  1. Axiom
  2. AXIOM-124

Serialization: Namespace declarations only output on first iteration

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Sun JDK 1.6, Axiom 1.2.2, Linux 2.6 (Fedora Core 5)
      and
      Sun JDK 1.5.0_11, Axiom 1.2.4, STAX (RI) 1.1.2-dev and 1.2.0 (final), Linux 2.6 (Ubuntu)

      Description

      When serializing a document that contains many child nodes using the same namespace that is NOT declared on the root,
      only the first namespace declaration is output, even if multiple elements require it;

      e.g. document contains root element "root" and two children "foo" and "bar", both in the namespace "http://example.com/ns", which is NOT
      declarted on root, should be serialized as:

      <root>
      <ns:foo xmlns:ns="http://example.com/ns">foo contents</ns:foo>
      <ns:bar xmlns:ns="http://example.com/ns">bar contents</ns:foo>
      </root>

      but w/AXIOM 1.2.2 and default StAX parser shipped w/Sun JDK 1.6.0 (SJSXP 1.0?), output is:

      <root>
      <ns:foo xmlns:ns="http://example.com/ns">foo contents</ns:foo>
      <ns:bar>bar contents</ns:foo>
      </root>

      I have further verified that the problem does not occur if Woodstox 2.0.5 is used as the StAX implementation.

      I am not able to verify whether this is due to a bug in Sun's StAX implementation, or in the use AXIOM makes of the various classes. Possible reference issue for SJXSP: https://sjsxp.dev.java.net/issues/show_bug.cgi?id=31

      1. OMElementSerializationTest.java
        3 kB
        Alex Boisvert
      2. DeclTest.java
        1 kB
        Adam Constabaris

        Activity

        Hide
        Hudson added a comment -

        Integrated in ws-axiom-trunk #456 (See https://builds.apache.org/job/ws-axiom-trunk/456/)
        AXIOM-311: Refactored the regression test for AXIOM-124 so that it fits into the new test suite.

        veithen :
        Files :

        • /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/DeclTest.java
        • /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/resources/conformance/AXIOM-124.xml
        Show
        Hudson added a comment - Integrated in ws-axiom-trunk #456 (See https://builds.apache.org/job/ws-axiom-trunk/456/ ) AXIOM-311 : Refactored the regression test for AXIOM-124 so that it fits into the new test suite. veithen : Files : /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/DeclTest.java /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/resources/conformance/ AXIOM-124 .xml
        Andreas Veithen made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Andreas Veithen made changes -
        Project WS-Commons [ 12310250 ] Axiom [ 12311190 ]
        Key WSCOMMONS-175 AXIOM-124
        Component/s AXIOM [ 12310703 ]
        Davanum Srinivas made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Resolved [ 5 ]
        Hide
        Davanum Srinivas added a comment -

        Thanks Sanka, that was a great tip. Checked in a fix - svn revision 555034

        – dims

        Show
        Davanum Srinivas added a comment - Thanks Sanka, that was a great tip. Checked in a fix - svn revision 555034 – dims
        Hide
        Sanka Samaranayake added a comment -

        I think I found what cause the behavior. If you run the code[1] using woodstox stax implementation it will result 'null' and using sjaxp stax implementation it will result 'urn:foo'.

        Is this a defect in one of the implementations or is it something which is not clearly defined by the spec. ?

        [1] ByteArrayOutputStream baos = new ByteArrayOutputStream();
        XMLOutputFactory outputFactory = XMLOutputFactory.newInstance();
        outputFactory.setProperty(XMLOutputFactory.IS_REPAIRING_NAMESPACES,
        Boolean.FALSE);
        XMLStreamWriter writer = outputFactory.createXMLStreamWriter(baos);
        NamespaceContext namespaceContext = writer.getNamespaceContext();

        writer.writeStartElement("ns1", "foo", "urn:foo");
        System.out.println("Namespace associated 'ns1' prefix : "
        namespaceContext.getNamespaceURI("ns1"));

        Show
        Sanka Samaranayake added a comment - I think I found what cause the behavior. If you run the code [1] using woodstox stax implementation it will result 'null' and using sjaxp stax implementation it will result 'urn:foo'. Is this a defect in one of the implementations or is it something which is not clearly defined by the spec. ? [1] ByteArrayOutputStream baos = new ByteArrayOutputStream(); XMLOutputFactory outputFactory = XMLOutputFactory.newInstance(); outputFactory.setProperty(XMLOutputFactory.IS_REPAIRING_NAMESPACES, Boolean.FALSE); XMLStreamWriter writer = outputFactory.createXMLStreamWriter(baos); NamespaceContext namespaceContext = writer.getNamespaceContext(); writer.writeStartElement("ns1", "foo", "urn:foo"); System.out.println("Namespace associated 'ns1' prefix : " namespaceContext.getNamespaceURI("ns1"));
        Davanum Srinivas made changes -
        Status Resolved [ 5 ] Reopened [ 4 ]
        Resolution Cannot Reproduce [ 5 ]
        Assignee Eran Chinthaka [ eran chinthaka ] Davanum Srinivas [ dims ]
        Hide
        Davanum Srinivas added a comment -

        This is not a blocker, but definitely a bug

        Show
        Davanum Srinivas added a comment - This is not a blocker, but definitely a bug
        Eran Chinthaka made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Cannot Reproduce [ 5 ]
        Hide
        Eran Chinthaka added a comment -

        I just tested this within Axiom using woodstox 3.0 and sjsxp 1.0 version and the provided test was successful without any issue.

        I added the provided test case in to org.apache.axiom.om.NamespaceTest. Please see the last test method.

        I also tested the namespace declaration issue shown in DeclTest and it was working fine with woodstox (didn't check with sjsxp). We had couple of problems earlier also with sjsxp and we moved to woodstox some time back. The simple reason was there were some holes in JSR173 itself for namespace handling. If this issue is only with sjsxp and works fine with woodstox, I do not consider this as a blocker as our main concern is with woodstox.
        If you feel this should be fixed for sjsxp, please re-open this issue, but this won't regarded as a critical or blocker

        Show
        Eran Chinthaka added a comment - I just tested this within Axiom using woodstox 3.0 and sjsxp 1.0 version and the provided test was successful without any issue. I added the provided test case in to org.apache.axiom.om.NamespaceTest. Please see the last test method. I also tested the namespace declaration issue shown in DeclTest and it was working fine with woodstox (didn't check with sjsxp). We had couple of problems earlier also with sjsxp and we moved to woodstox some time back. The simple reason was there were some holes in JSR173 itself for namespace handling. If this issue is only with sjsxp and works fine with woodstox, I do not consider this as a blocker as our main concern is with woodstox. If you feel this should be fixed for sjsxp, please re-open this issue, but this won't regarded as a critical or blocker
        Eran Chinthaka made changes -
        Assignee Eran Chinthaka [ eran chinthaka ]
        Priority Major [ 3 ] Blocker [ 1 ]
        Alex Boisvert made changes -
        Environment Sun JDK 1.6, Axiom 1.2.2, Linux 2.6 (Fedora Core 5) Sun JDK 1.6, Axiom 1.2.2, Linux 2.6 (Fedora Core 5)
        and
        Sun JDK 1.5.0_11, Axiom 1.2.4, STAX (RI) 1.1.2-dev and 1.2.0 (final), Linux 2.6 (Ubuntu)
        Hide
        Alex Boisvert added a comment -

        I just retried with Axiom 1.2.4 and STAX (RI) 1.1.2-dev and 1.2.0. Both fail in the same way on JDK 1.5.0_11 (Linux/Ubuntu)

        Show
        Alex Boisvert added a comment - I just retried with Axiom 1.2.4 and STAX (RI) 1.1.2-dev and 1.2.0. Both fail in the same way on JDK 1.5.0_11 (Linux/Ubuntu)
        Hide
        Alex Boisvert added a comment -

        Also wanted to point out that not only can Axiom output invalid XML (without namespace declaration for elements after the first one), but my test case also shows that AXIOM can parse the same invalid XML without complaining.... it simply ignores the invalid elements!

        Show
        Alex Boisvert added a comment - Also wanted to point out that not only can Axiom output invalid XML (without namespace declaration for elements after the first one), but my test case also shows that AXIOM can parse the same invalid XML without complaining.... it simply ignores the invalid elements!
        Alex Boisvert made changes -
        Attachment OMElementSerializationTest.java [ 12356371 ]
        Hide
        Alex Boisvert added a comment -

        I stumbled upon this bug as well and wrote a JUnit test for it.

        Fails for Axiom 1.2.2-1.2.4; I have not tested earlier versions.

        Show
        Alex Boisvert added a comment - I stumbled upon this bug as well and wrote a JUnit test for it. Fails for Axiom 1.2.2-1.2.4; I have not tested earlier versions.
        Hide
        Ryan Nelsestuen added a comment -

        After looking at this for a while, I think the problem is that some XMLStreamWriters are pushing an additional default namespace declaration onto its internal stack when Axiom calls

        writer.writeStartElement("", localName, eNamespace);

        In other words, it is repeating the work done by the

        generateSetPrefix(prefix, namespace, writer, true);

        (If you look at the OMSerializerUtil class you can see why woodstox is treated differently).

        The point of contention is probably whether the writeStartElement method should in fact implicitly add to the namespace context or not. An alternate work-around might be to change

        if (setPrefixFirst) {
        if (eNamespace != null) {
        if (ePrefix == null)

        { writer.writeStartElement("", localName, eNamespace); }

        else

        { writer.writeStartElement(ePrefix, localName, eNamespace); }


        } else

        { writer.writeStartElement(localName); }


        }

        to use a different version of the writeStartElement method, and/or to pull the namespace context and check for the existence of the NS/prefix combo and decide which writeStartElement to call based on that.

        Show
        Ryan Nelsestuen added a comment - After looking at this for a while, I think the problem is that some XMLStreamWriters are pushing an additional default namespace declaration onto its internal stack when Axiom calls writer.writeStartElement("", localName, eNamespace); In other words, it is repeating the work done by the generateSetPrefix(prefix, namespace, writer, true); (If you look at the OMSerializerUtil class you can see why woodstox is treated differently). The point of contention is probably whether the writeStartElement method should in fact implicitly add to the namespace context or not. An alternate work-around might be to change if (setPrefixFirst) { if (eNamespace != null) { if (ePrefix == null) { writer.writeStartElement("", localName, eNamespace); } else { writer.writeStartElement(ePrefix, localName, eNamespace); } } else { writer.writeStartElement(localName); } } to use a different version of the writeStartElement method, and/or to pull the namespace context and check for the existence of the NS/prefix combo and decide which writeStartElement to call based on that.
        Adam Constabaris made changes -
        Field Original Value New Value
        Attachment DeclTest.java [ 12352230 ]
        Hide
        Adam Constabaris added a comment -

        Test case illustrating the problem (must be using JDK 1.6 default StAX implementation)

        Show
        Adam Constabaris added a comment - Test case illustrating the problem (must be using JDK 1.6 default StAX implementation)
        Adam Constabaris created issue -

          People

          • Assignee:
            Davanum Srinivas
            Reporter:
            Adam Constabaris
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development