Woodstox

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. Text File
    readme.txt
    28/Oct/11 9:20 AM
    3 kB
    kalyan valluri
  3. Java Source File
    TestWoodstoxReader.java
    22/Dec/11 8:57 AM
    1 kB
    kalyan valluri
  4. Java Source File
    TestWoodstoxReader.java
    22/Dec/11 8:56 AM
    1 kB
    kalyan valluri

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

Quick sanity check: are you sure property "javax.xml.stream.isCoalescing" is set to true? Without it, CHARACTERS and CDATA events are not combined.
Reason I am asking is that 3.2 incorrectly defaulted this property to 'true', and 4.x fixes this to specification-mandated default (false).

Show
Tatu Saloranta added a comment - Quick sanity check: are you sure property "javax.xml.stream.isCoalescing" is set to true? Without it, CHARACTERS and CDATA events are not combined. Reason I am asking is that 3.2 incorrectly defaulted this property to 'true', and 4.x fixes this to specification-mandated default (false).
Hide
Permalink
kalyan valluri added a comment -

Hi Tatu,
Im not sure if "javax.xml.stream.isCoalescing" is set to true or not.I could reproduce the issue using the same attached test case on Weblogic 10.3.4 which uses woodstox 4.0.5.The same test case works just fine on weblogic 10.3.2 and earlier. Appreciate any hints/pointers.

Best Regards,
Kalyan.

Show
kalyan valluri added a comment - Hi Tatu, Im not sure if "javax.xml.stream.isCoalescing" is set to true or not.I could reproduce the issue using the same attached test case on Weblogic 10.3.4 which uses woodstox 4.0.5.The same test case works just fine on weblogic 10.3.2 and earlier. Appreciate any hints/pointers. Best Regards, Kalyan.
Hide
Permalink
Tatu Saloranta added a comment -

What I really need is to reproduce this outside of weblogic. That way unit test can be added to woodstox test suite, if there is a bug to fix.

Show
Tatu Saloranta added a comment - What I really need is to reproduce this outside of weblogic. That way unit test can be added to woodstox test suite, if there is a bug to fix.
Hide
Permalink
kalyan valluri added a comment -

Hi Tatu,
I checked with Weblogic Development team and they informed that the issue stems from woodstox layer as this works just fine till
WLS 10.3.2 and there must have been some change that causes this behavior (On and above 4.0.5) from weblogic 10.3.3.

Please provide any suggestions as to how this should be reproduced outside of weblogic.

Thanks,
Kalyan.

Show
kalyan valluri added a comment - Hi Tatu, I checked with Weblogic Development team and they informed that the issue stems from woodstox layer as this works just fine till WLS 10.3.2 and there must have been some change that causes this behavior (On and above 4.0.5) from weblogic 10.3.3. Please provide any suggestions as to how this should be reproduced outside of weblogic. Thanks, Kalyan.
Hide
Permalink
Tatu Saloranta added a comment -

Outside of weblogic means that test case should not depend on additional containers: ideally a simple unit test would reproduce this. There are multiple variations that can affect things: whether input is read using InputStream or Reader, for example; as well as buffer edge conditions. I understand that it may be difficult to trigger this, but I have to be able to reproduce this via unit tests before I can fix it.

Also, make sure to test using latest 4.0 version (4.0.10) – some
issues have been fixed since 4.0.5. Specifically if you look at VERSION document, this:

—
4.0.6 [01-Oct-2009]

Problems fixed:

  • WSTX-211: Failure to parse long CDATA section properly when
    using XMLStreamReader.getElementText(), non-coalescing
    (reported by Kevin B)
    —

looks like it could be what you are experiencing.

Show
Tatu Saloranta added a comment - Outside of weblogic means that test case should not depend on additional containers: ideally a simple unit test would reproduce this. There are multiple variations that can affect things: whether input is read using InputStream or Reader, for example; as well as buffer edge conditions. I understand that it may be difficult to trigger this, but I have to be able to reproduce this via unit tests before I can fix it. Also, make sure to test using latest 4.0 version (4.0.10) – some issues have been fixed since 4.0.5. Specifically if you look at VERSION document, this: — 4.0.6 [01-Oct-2009] Problems fixed: WSTX-211 : Failure to parse long CDATA section properly when using XMLStreamReader.getElementText(), non-coalescing (reported by Kevin B) — looks like it could be what you are experiencing.
Hide
Permalink
kalyan valluri added a comment -

Hi Tatu,
Weblogic Development team informed that they tried the latest version 4.1.2, the issue is still not fixed.

Thanks,
Kalyan.

Show
kalyan valluri added a comment - Hi Tatu, Weblogic Development team informed that they tried the latest version 4.1.2, the issue is still not fixed. Thanks, Kalyan.
Hide
Permalink
Tatu Saloranta added a comment -

Thank you for verifying that the issue still exists.

What is needed then is a unit test to reproduce the problem. There are many variations and it is hard to find problematic case without knowing the right combination (Reader vs InputStream, XMLStreamReader vs XMLEventReader, coalescing/non-coalescing, content used).
I did see the test attached, but it seems to require running weblogic (which I assume also has the code that has details of how xml is actually processed using Stax API).

Show
Tatu Saloranta added a comment - Thank you for verifying that the issue still exists. What is needed then is a unit test to reproduce the problem. There are many variations and it is hard to find problematic case without knowing the right combination (Reader vs InputStream, XMLStreamReader vs XMLEventReader, coalescing/non-coalescing, content used). I did see the test attached, but it seems to require running weblogic (which I assume also has the code that has details of how xml is actually processed using Stax API).
Hide
Permalink
kalyan valluri added a comment -

Hi Tatu,
I quickly tested by setting with -Djavax.xml.stream.isCoalescing=true in first run and the -Djavax.xml.stream.isCoalescing=true.

However both the settings didn't seem to address the issue.

Best Regards,
Kalyan.

Show
kalyan valluri added a comment - Hi Tatu, I quickly tested by setting with -Djavax.xml.stream.isCoalescing=true in first run and the -Djavax.xml.stream.isCoalescing=true. However both the settings didn't seem to address the issue. Best Regards, Kalyan.
Hide
Permalink
Tatu Saloranta added a comment -

As I said, I need to be able to reproduce the issue to be able to fix it. And the best way to reproduce it is to have a stand-alone unit test.

Show
Tatu Saloranta added a comment - As I said, I need to be able to reproduce the issue to be able to fix it. And the best way to reproduce it is to have a stand-alone unit test.
Hide
Permalink
kalyan valluri added a comment -

Hi Tatu,
We created a standalone reproducer:TestWoodstoxReader.java

The output I get is:
class com.ctc.wstx.sr.ValidatingStreamReader
4
outside cdata

Could you please review and let me know your thoughts?

Thanks,
Kalyan.

Show
kalyan valluri added a comment - Hi Tatu, We created a standalone reproducer:TestWoodstoxReader.java The output I get is: class com.ctc.wstx.sr.ValidatingStreamReader 4 outside cdata Could you please review and let me know your thoughts? Thanks, Kalyan.
Hide
Permalink
kalyan valluri added a comment -

Attaching standalone reproducer.

Show
kalyan valluri added a comment - Attaching standalone reproducer.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: