XStream

PropertiesConverter does not handle tabs and newlines

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.4.2
  • Component/s: None
  • Labels:
    None
  • JDK version and platform:
    Sun 1.4.2_08-b03 for Windows

Description

PropertiesConverter makes some bad assumptions about the Strings that
appear in the name-value pairs. From the PropertiesConverter javadoc:

Special converter for java.util.Properties that stores properties in a
more compact form than java.util.Map. Because all entries of a
Properties instance are Strings, a single element is used for each
property with two attributes; one for key and one for value.

The problem is that the XML spec
(http://www.w3.org/TR/REC-xml/#AVNormalize) and the
org.xmlpull.mxp1.MXParser "normalize" attributes to remove tabs,
newlines, and carriage returns.

So a value inside a Properties object called "my<tab>property" gets
normalized to "my<space>property" when reading the attribute (see
MXParser.parseAttribute()).

When writing Properties to a file, Java escapes the tabs with a \t so
that it would appear in the property files as

key=my\tproperty

PropertiesConverter should probably be removed entirely and Properties
should be encoded just like any other Map using XML entities. It could
still use attributes, but it would have to use [[CDATA]] in order to
work with the XML spec.

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. XSTR-269 Attribute capability to XStream

  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

New Feature - A new feature of the product, which has yet to be developed. XSTR-62 Make an option to create primitive and String properties as attributes.

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
sebastien mignot added a comment -

Hi
As discussed with Jörg Schaible in the user's mailing list, XStream's PrettyPrintWriter should treat & escape '\n' and '\t' the same way it treats & escape '\r' (else the xml parseur on the other end will just replace them by white-spaces). This should be the case for the values as well as for the attributes (anyway, the PrettyPrintWriter's escaping is done in a single method for the 2, so there is only the writeText method to change.
And btw, thank's for the great lib !

Show
sebastien mignot added a comment - Hi As discussed with Jörg Schaible in the user's mailing list, XStream's PrettyPrintWriter should treat & escape '\n' and '\t' the same way it treats & escape '\r' (else the xml parseur on the other end will just replace them by white-spaces). This should be the case for the values as well as for the attributes (anyway, the PrettyPrintWriter's escaping is done in a single method for the 2, so there is only the writeText method to change. And btw, thank's for the great lib !
Hide
Permalink
Jörg Schaible added a comment -

Sadly that I never realized that the XML spec is quite clear: Attributes are written by default as CDATA. And while '\n', '\t' and '\r' are replaced with spaces by the attribute normalization, they are replaced with the real character if these characters are delivered as entities. Therefore will the PrettyPrintWriter (and derived) encode these characters now with entities. Note, that the writers based on 3rd party code may still fail to do so. BEA's and Woodstox' StAX writer and the XOM writer are compliant and will encode these whitespace characters, while JDK's StAX writer and Dom4J's XML writer fail.

Show
Jörg Schaible added a comment - Sadly that I never realized that the XML spec is quite clear: Attributes are written by default as CDATA. And while '\n', '\t' and '\r' are replaced with spaces by the attribute normalization, they are replaced with the real character if these characters are delivered as entities. Therefore will the PrettyPrintWriter (and derived) encode these characters now with entities. Note, that the writers based on 3rd party code may still fail to do so. BEA's and Woodstox' StAX writer and the XOM writer are compliant and will encode these whitespace characters, while JDK's StAX writer and Dom4J's XML writer fail.

People

  • Assignee:
    Jörg Schaible
    Reporter:
    Scott McFarland
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: