Woodstox
  1. Woodstox
  2. WSTX-274

If a request contains <FieldA>outside cdata <![CDATA[inside <data> cdata]]></FieldA>, the transformed string will become <FieldA>outside cdata </FieldA>. I.e. the CDATA segment is completely missing in the result.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      All operating systems.
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      On WLS 10.3.4 deployed a webservice and invoking it from client on the same machine.Segment in soap request ignored when transformed to a string.

      If a request contains <FieldA>outside cdata <![CDATA[inside <data>
      cdata]]></FieldA>, the transformed string will become <FieldA>outside cdata
      </FieldA>. I.e. the CDATA segment is completely missing in the result.

      Below is the snippet from WLS 10.3.4 log with webservice debug enabled

      <ServletDebugUtil.printRequest:34>

        • S T A R T I N P U T S T R E A M **
          Sep 13, 2011 4:01:13 PM com.sun.xml.ws.transport.http.HttpAdapter
          fixQuotesAroundSoapAction
          INFO: Received WS-I BP non-conformant Unquoted SoapAction HTTP header:
          INFO com.sun.xml.ws.transport.http.HttpAdapter Received WS-I BP
          non-conformant Unquoted SoapAction HTTP header:

      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body>
      <echoRequest xmlns="http://test.ibm.com/xsd">
      <arg0>outside cdata <![CDATA[<data>inside cdata</data>]]></arg0>
      </echoRequest>
      </soapenv:Body>
      </soapenv:Envelope>** E N D I N P U T S T R E A M **

      When trying to parse this xml with javax.xml.transform.Transformer notice
      below snippet on WLS 10.3.4

      =====================Request payload================

      <?xml version="1.0" encoding="UTF-8"?><echoRequest
      xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns="http://test.ibm.com/xsd">
      <arg0>outside cdata </arg0>
      </echoRequest>

      ====================================================
      However this seems to work fine in prior releases of weblogic from WLS 10.3 till 10.3.2

      It appears to be a bug in woodstox parser.It was fine in woodstox3.2.5.The issue seems to stem after from 4.0.5

      1. readme.txt
        3 kB
        kalyan valluri
      2. TestWoodstoxReader.java
        1 kB
        kalyan valluri
      3. TestWoodstoxReader.java
        1 kB
        kalyan valluri

        Activity

        Hide
        kalyan valluri added a comment -

        Attaching standalone reproducer.

        Show
        kalyan valluri added a comment - Attaching standalone reproducer.
        Hide
        Tatu Saloranta added a comment -

        Great! I should be able to test it out today.

        Show
        Tatu Saloranta added a comment - Great! I should be able to test it out today.
        Hide
        Tatu Saloranta added a comment -

        What I can reproduce is that when coalescing is not enabled, behavior is to not coalesce; but when coalescing is explicitly enabled, things work. I don't usually use system properties for this, so this part of functionality is not well tested.

        Show
        Tatu Saloranta added a comment - What I can reproduce is that when coalescing is not enabled, behavior is to not coalesce; but when coalescing is explicitly enabled, things work. I don't usually use system properties for this, so this part of functionality is not well tested.
        Hide
        Tatu Saloranta added a comment -

        Actually: I don't think Stax is supposed to use system properties at all, beyond optionally using it to locate XMLInputFactory/XMLOutputFactory instances.
        So test is invalid; setting has no effect. Instead, one needs to configure instance like so:

        factory.setProperty(XMLInputFactory.IS_COALESCING, true);

        which does work. So I think test itself is invalid.

        Now, the reason why this behaved differently in 3.2 is simply that the default settings for IS_COALESCING was 'true', which is incorrect as per specification, and 4.0 changed this to 'false' as per spec.
        Setting did not have any effect, but default was different.

        Show
        Tatu Saloranta added a comment - Actually: I don't think Stax is supposed to use system properties at all, beyond optionally using it to locate XMLInputFactory/XMLOutputFactory instances. So test is invalid; setting has no effect. Instead, one needs to configure instance like so: factory.setProperty(XMLInputFactory.IS_COALESCING, true); which does work. So I think test itself is invalid. Now, the reason why this behaved differently in 3.2 is simply that the default settings for IS_COALESCING was 'true', which is incorrect as per specification, and 4.0 changed this to 'false' as per spec. Setting did not have any effect, but default was different.
        Hide
        Tatu Saloranta added a comment -

        As far as I can see, there's bit of misunderstanding on use of system properties; but no actual bug.

        Show
        Tatu Saloranta added a comment - As far as I can see, there's bit of misunderstanding on use of system properties; but no actual bug.

          People

          • Assignee:
            Tatu Saloranta
            Reporter:
            kalyan valluri
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: