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
