Hi,
Thanks for the quick response.
Yes I can see now that it would be problematic in some cases, although
OK in others, so overall might be difficult to attempt to work it in as
a clean feature.
The basic requirement is to apply default mappings to an XStream
instance that can then be selectively overridden (by some other piece of
external logic) to encourage a consistent (and particular) style of XML.
This isn't possible currently then and based on what you said isn't
going to get implemented either, so I'll work around it.
I can apply defaults that can be overridden (aliases), then have the
external logic indicate what it is interested in applying mappings to
(which fields) and then apply default mappings to any fields not
touched. It's not ideal but it will work well enough for our purposes.
Thanks again.
On 01/11/12 17:56, Jörg Schaible wrote:
Antony Warner wrote:
Hi,
I've a situation where I can't currently see how to quite achieve a
requirement I have using XStream as a Java/XML mapper.
The background is we have a UML model off of which we generate Java
classes that are persisted to XML using XStream.
The requirement is that I'd like to apply some default mappings
(mappings as in aliases and converters to influence the way the XML
looks) to an XStream instance, and then pass the instance off to some
other code that can then choose to selectively override those defaults.
The defaults can be applied by either annotations or Java code, I don't
think that matters to the ultimate behaviour of XStream. I'd probably
choose to generate XStream annotations into the generated classes.
In the case of aliases, this works nicely. In my (quite bad) example
below, I've applied defaults using annotations. The test class outputs
the XML produced by the defaults, then I override an alias and output it
again showing that the default has been overridden (the alias is just
overridden in xstream.mapper.ClassAliasingMapper).
This doesn't however work when we choose to use XML attributes rather
than elements. The default for Book.title is an attribute, but there is
no way to override that, once we've set it (there is no way to remove
the field that has been written into
xstream.mapper.AttributeMapper.fieldToUseAsAttribute).
The same issue is there for converters, once set, there is no way to
unset them (no way to remove them from
xstream.mapper.LocalConversionMapper.localConverters).
I can probably figure out ways of achieving this, however so far they
all involve a lot of overriding of XStream classes to change or add
behaviour.
So the first question is, is there a better XStream mechanism to achieve
what I want to do?
If not, would it be a reasonable feature request to allow these sorts of
mappings to be unset on an XStream instance? I think this can be done by
extra API calls on XStream that then unset things on mappers like
AttributeMapper and LocalConversionMapper. For example
XStream.useElementFor methods, XStream.unregisterConverter methods, and
XStream.unregisterLocalConverter methods. XStream.useElementFor for
example would ask AttributeMapper to remove a field from it's internal
Set.
What do you think? I look forward to feedback on this.
[snip]
Well, 8 years ago someone else asked for this, see XSTR-160. ;-)
Just in case you ask yourself why Guilherme never applied his own patch, it
was simply not practical:
xstream.registerConverter(new ToStringConverter(URL.class));
xstream.registerConverter(new ToStringConverter(URI.class));
xstream.unregisterConverter(???);
Typically you do not have the instance of the converter, nor do you really
know which type(s) a converter handles:
xstream.unregisterConverterOfType(ToStringConverter.class);
// oops, we had no idea how many instances actually were registered
xstream.unregisterConverterForType(LinkedList.class);
// oops, we removed also the converter for ArrayList, HashSet, Vector, ...
For converters and aliases it is actually possible to override a setting
just by defining a new one - as you have found out yourself, but you're
right, such a possibility does not exist for the definitions of attributes,
immutable types, default implementation types, implicit
collections/maps/arrays ...
Using such functionality in combination with annotation auto-detection will
have side-effects. Using it while marshalling/unmarshalling will provoke
undefined behavior due to internal caches. However, this is already partly
true for calling setup methods in this state.
So, these were the facts. What do you really need of this? AFAICS it is
currently only the possibility to remove the attribute flag again.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Antony Warner
Software Developer
Gresham Computing PLC
e: [email protected]
w: http://www.gresham-computing.com
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Gresham does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Gresham does not accept liability for any damage sustained as a result of viruses. Statements in this message that do not relate to the business of Gresham are neither given nor endorsed by the company or its directors. Gresham Computing plc Registered in England and Wales. Company No. 01072032 Registered Office: Sopwith House, Brook Avenue, Warsash, Southampton. Hants. SO31 9ZA Further information about Gresham Computing can be found on our website: www.gresham-computing.com
