Thanks for the quick replies J?rg,
with my software being at version 0.9, with no customers yet, I'm all for
compatibility breaking ?. Especially since this is an issue blocking our
release.?
That said I suspect the vast majority of your users wouldn't be.
Perhaps a nice middle ground is to simply never include xpaths for primitives,
which I suspect you've been serializing plainly for quite some time?
Alternatively, make it user configurable? Our XStream configuration is already
fairly extensive, I don't see much harm in making it a little bit more
extensive, but I'm sure no library author likes to hear that.
void addImmutableType(Class clazz) { addImmutableType(clazz,
XPathPolicy.BACKWARDS_COMPATIBLE); }
void addImmutableType(Class clazz, XPathPolicy pathPolicy){ ... }
enum XPathPolicy{ ALWAYS_RETAIN_PATH, BACKWARDS_COMPATIBLE, NEVER_RETAIN_PATH }
with `BACKWARDS_COMPATIBLE` meaning don't keep the map during serialization,
but do keep the map on deserialization.
I've also only thrown the ALWAYS_RETAIN_PATH option up there for completeness,
I have no idea why you would want it. I suppose if somebody's doing something
particularly complex in a custom converter, they could conceivably use the
immutable type concept for purpose known only to them, their domain, and their
converter, and involve this 'immutable type but always use paths' mode.
I'm going to write this up now.
Thanks for the help and the great library!
-Geoff
From: J?rg Schaible<mailto:joerg.schai...@gmx.de>
Sent: ?Tuesday?, ?April? ?21?, ?2015 ?5?:?35? ?PM
To: user@xstream.codehaus.org<mailto:user@xstream.codehaus.org>
Hi Geoff,
Geoff Groos wrote:
> I'm on XStream 1.4.7 (I'll get myself current in a moment)
>
> I'm looking at line 67 of the AbstractReferenceUnmarshaller where it's
> putting the integer `10` in as a value for the reference-key
> ".../myModelMatrixClass/widthOfMatrix". The field corresponding to that
> path is an 'int'.
>
> the myModelMatrix type does use a custom converter which extends the
> ReflectionConverter, but it uses the stock `unmarshalField` method to
> unmarshall that field, which in turn is hitting the
> 'abstractReferenceUnmarshaller' to unmarshall the '10' value at the
> element <widthOfMatrix>10</widthOfMatrix>
>
> I hope I'm describing this accurately. I could start putting together an
> SSCCE if it would help.
OK. My bad, I've looked at the marshaller only. Basically you're right, but
if we throw away the references for immutables, we might introduce a
compatibility problem:
==================== %< =========================
UUID[] uuidArray = new UUID[2];
uuidArray[0] = uuidArray[1] = UUID.randomUUID();
XStream xstream = new XStream();
String xml = xstream.toXML(uuidArray);
// unmarshal in later version of application with a changed setup:
XStream xstream = new XStream();
xstrea.addImmutable(UUID.class);
xstream.fromXML(xml); // XStreamException, reference not found
==================== %< =========================
See, I've already set UUID as immutable for 1.4.9. If we drop also the
references to any immutable, anybody with an XML containing a reference to a
UUID will fail at deserialization. :-/
Cheers,
J?rg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
