Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.4.7
-
Fix Version/s: 1.4.9
-
Component/s: Converters
-
Labels:None
Description
As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the AbstractReferenceUnmarshaller's xpath map.
To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type X is serialized with an early version of XStream that considers it not to be immutable, and then later deserialized with a version of XStream that does consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep.
Activity
Field | Original Value | New Value |
---|---|---|
Summary | Exclude Immutable types from xpath system on deserialization | Exclude Immutable types from xpath entry on deserialization |
Description |
> As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the `AbstractReferenceUnmarshaller`'s xpath map. To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type X is serialized with an early version of XStream that considers it _not_ to be immutable, and then later deserialized with a version of XStream that _does_ consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep. |
> As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the {{AbstractReferenceUnmarshaller}}'s xpath map. To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type X is serialized with an early version of XStream that considers it _not_ to be immutable, and then later deserialized with a version of XStream that _does_ consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep. |
Description |
> As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the {{AbstractReferenceUnmarshaller}}'s xpath map. To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type X is serialized with an early version of XStream that considers it _not_ to be immutable, and then later deserialized with a version of XStream that _does_ consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep. |
> As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the {{AbstractReferenceUnmarshaller}}'s xpath map. To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type {{X}} is serialized with an early version of XStream that considers it _not_ to be immutable, and then later deserialized with a version of XStream that _does_ consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep. |
Description |
> As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the {{AbstractReferenceUnmarshaller}}'s xpath map. To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type {{X}} is serialized with an early version of XStream that considers it _not_ to be immutable, and then later deserialized with a version of XStream that _does_ consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep. |
bq. As a developer I want to serialize and deserialize complex models without excessive use of xpath's so that I can use xstream on large documents with little memory overhead.
Currently XStream's use of XPaths is very selective in serialization (marshalling), but excessive in unmarshalling (deserialization). while unmarshalling documents, regardless immutability configuration, every instance will receive an xpath entry in the {{AbstractReferenceUnmarshaller}}'s xpath map. To complicate things, if this map is simply updated to follow the same behavior as serialization, then it would break compatibility with previous versions of xstream, as the default immutable types configuration changes. In the event that type {{X}} is serialized with an early version of XStream that considers it _not_ to be immutable, and then later deserialized with a version of XStream that _does_ consider it to be immutable, the resulting deserialization attempt will fail, as the document will contain and xpath entry that the deserializer will not keep. |
Attachment | xstream using 141mb + 70mb to desierialize 10mb file.png [ 67541 ] |
To give this issue a bit of punch, here is XStream using 210mb to deserialize a 10mb document: