Using more than one @XStreamAlias annotation for same element

[wertklop]

Improvement. I would like to have an implementation that support:

@XStreamAlias("alias1")
@XStreamAlias("alias2")
class ABC{

    @XStreamAlias("field1")
    @XStreamAlias("field2")
    String field;
}

Where xml node has been named any present aliases.
Thank's

[joehni]

You can do this without annotations using the XStream.alias() and XStream.aliasField() methods. However, this is no usual setup and you have to know, that a second alias definition will clobber the first one at serialization time, but will remain active for deserialization.

[sewe]

@joehni FWIW, I would also like to see @XStreamAlias be made @Repeatable. Of course, during serialization one of the alias definitions has to be picked, but as long as the choice is deterministic, I think there is not much risk of confusion. And it would really simplify working with types which (unfortunately) have suffered multiple rounds of renaming in the past (you know, naming is a hard problem).

[tetianakh]

@joehni I would like @XStreamAlias to be repeatable too. Clients send us XMLs with different names for the same fields, and we (sadly) have to support this. For example, the following snippets have to be treated identically:
<item-ids><item>123</item></item-ids> // lower case field name
<item-ids><Item>123</Item></item-ids> // capitalized field name

[bzurmaar]

Quite honestly I don't understand why this got closed so fast. It would be easy to make the annotation repeatable. The currenty state forces you to stray your meta data in annotations and extra-code when you want to have more than one alias. I support the original request. @tetianakh also delivered a scenario which developers find themselves in quite frequently.

[joehni]

So I keep it open for now...

[thhart]

Do I understand correct this makes serialized files compatible to classes which have renamed members?

[sewe]

Do I understand correct this makes serialized files compatible to classes which have renamed members?

At least, that was my use case for this feature: Support both the old and the new name of a member.