castor
  1. castor
  2. CASTOR-1593

AnyNode unmarshalling not preserving whitespaces

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.3
    • Fix Version/s: 1.0.4
    • Component/s: XML
    • Labels:
      None
    • Environment:
      Windows XP SP2, Eclipse 3.2, JDK 1.5.0_07
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      When marshalling a structure that contains an AnyNode element with pure whitespaces as text content the XML structure is serialized correctly with the whitespaces, however, once I unmarshall the same structure the whitespaces of the AnyNode element are not preserved.

      I tried the following settings to change this behaviour:

      • unmarshaller.setWhitespacePreserve(true);
      • Using DTD with attribute declaration xml:space="preserve"
      • Setting node attribute xml:space="preserve" directly

      For normal String elements these settings work as expected, but for an AnyNode element they don' have any influence.

      1. TextContentTest.java
        6 kB
        M.-Leander Reimer
      2. patch.c1593.20060930.txt
        12 kB
        Werner Guttmann

        Activity

        Hide
        M.-Leander Reimer added a comment -

        JUnit test case, mapping file, test entity, DTD file and README.

        The testcase contains 3 tests. Using version 1.0.3 two tests should fail at the assertEquals of the AnyNode after unmarshalling.

        Show
        M.-Leander Reimer added a comment - JUnit test case, mapping file, test entity, DTD file and README. The testcase contains 3 tests. Using version 1.0.3 two tests should fail at the assertEquals of the AnyNode after unmarshalling.
        Hide
        M.-Leander Reimer added a comment -

        This patch resolves the described problem, the unmarshalling now respects the whitespace preserve setting either set via the Unmarshaller, a DTD xml:space attribute.

        The test cases will all run sucessfully now.

        There is either one patch file for both files together, or one patch file each in the ZIP.

        Show
        M.-Leander Reimer added a comment - This patch resolves the described problem, the unmarshalling now respects the whitespace preserve setting either set via the Unmarshaller, a DTD xml:space attribute. The test cases will all run sucessfully now. There is either one patch file for both files together, or one patch file each in the ZIP.
        Hide
        Werner Guttmann added a comment -

        Interesting, after applying the patch, I still get two AssertionErrors .. .

        Show
        Werner Guttmann added a comment - Interesting, after applying the patch, I still get two AssertionErrors .. .
        Hide
        Werner Guttmann added a comment -

        Above patches as unified diff (relative to src/bugs).

        Show
        Werner Guttmann added a comment - Above patches as unified diff (relative to src/bugs).
        Hide
        M.-Leander Reimer added a comment -

        First of all sorry for the confusion and not testing from within the Castor project. I have a separate testing project and only used the patched Castor JAR as a dependency to run my tests. Next time I will run the tests from within Castor first before submitting.

        I did some debugging myself, and you are right the tests still fail, however, for a different reason. The test string contains a \r which is not marshalled / unmarshalled correctly!! After unmarshalling the \r turned into a \n and that's why the tests fail at the string node comparison already.

        The difference to my private testing project was, that I use Xerces-J 2.80 instead of Xerces-J 1.4.0! After changing the dependency, the \r is now marshalled as which is then unmarshalled into the \r again correctly.

        I have tested a couple of other Xerces version that I had in my maven repo, the results are:

        • Xerces 2.4.0: Not working! Again, the \r is not marshalled and unmarshalled correctly.
        • Xerces 2.6.2: Working as expected, the \r is marshalled as and unmarshalled into \r again.
        • Xerces 2.8.0: Working as expected, .....

        So changing the Xerces dependency to a more recent version does the trick

        Show
        M.-Leander Reimer added a comment - First of all sorry for the confusion and not testing from within the Castor project. I have a separate testing project and only used the patched Castor JAR as a dependency to run my tests. Next time I will run the tests from within Castor first before submitting. I did some debugging myself, and you are right the tests still fail, however, for a different reason. The test string contains a \r which is not marshalled / unmarshalled correctly!! After unmarshalling the \r turned into a \n and that's why the tests fail at the string node comparison already. The difference to my private testing project was, that I use Xerces-J 2.80 instead of Xerces-J 1.4.0! After changing the dependency, the \r is now marshalled as which is then unmarshalled into the \r again correctly. I have tested a couple of other Xerces version that I had in my maven repo, the results are: Xerces 2.4.0: Not working! Again, the \r is not marshalled and unmarshalled correctly. Xerces 2.6.2: Working as expected, the \r is marshalled as and unmarshalled into \r again. Xerces 2.8.0: Working as expected, ..... So changing the Xerces dependency to a more recent version does the trick
        Hide
        M.-Leander Reimer added a comment -

        The \r is marshalled as "& # x d;" (added spaces to preserve the entity)

        Show
        M.-Leander Reimer added a comment - The \r is marshalled as "& # x d;" (added spaces to preserve the entity)
        Hide
        Werner Guttmann added a comment -

        Thanks for the feedback. Could you possibly maybe amend the test case so that a \r is not used. I'd still love to have a working test case which I could add the test suite. Other than that, interesting findings ......

        Show
        Werner Guttmann added a comment - Thanks for the feedback. Could you possibly maybe amend the test case so that a \r is not used. I'd still love to have a working test case which I could add the test suite. Other than that, interesting findings ..... .
        Hide
        M.-Leander Reimer added a comment -

        Here is my amended test case without the \r in the test string. I first applied the patch you created (patch.c1593.20060930.txt) and then simply changed the string.

        The tests run successfully with Xerces-J 1.4.0 as dependency now, though in my opinion using a more recent version of Xerces would be a better solution since \r is a valid whitespace and the behaviour not only applies to anynode elements but to simple string elements also.

        Show
        M.-Leander Reimer added a comment - Here is my amended test case without the \r in the test string. I first applied the patch you created (patch.c1593.20060930.txt) and then simply changed the string. The tests run successfully with Xerces-J 1.4.0 as dependency now, though in my opinion using a more recent version of Xerces would be a better solution since \r is a valid whitespace and the behaviour not only applies to anynode elements but to simple string elements also.
        Hide
        Werner Guttmann added a comment -

        Thank you so much. I agree that switching to a newer version should be possible, but we have to resolve a few dependencies first, such as removing AdaptX first and making sure that switching to a newer version does not break pretty printing with Castor.

        Show
        Werner Guttmann added a comment - Thank you so much. I agree that switching to a newer version should be possible, but we have to resolve a few dependencies first, such as removing AdaptX first and making sure that switching to a newer version does not break pretty printing with Castor.

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            M.-Leander Reimer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: