Default name ignored on @XmlElementWrapper

[Vulcannis]

@XmlElementWrapper (with USE_WRAPPER_NAME_AS_PROPERTY_NAME enabled) only works if the name parameter is given an explicit value. By default it should use the property name, but Jackson uses the name given in the @xmlelement attribute instead. e.g.,

@xmlelement( name = "a" )
@XmlElementWrapper
public List< String > b;

Should result in:
"b": [ ]
but is instead:
"a": [ ]

I believe this is because JaxbAnnotationIntrospector.findWrapperName simply passes "" as the default name to _combineNames, which then fails the !wrapperName.hasSimpleName( ) test in POJOPropertiesCollector._renameWithWrappers( ).

[cowtowncoder]

@XmlElementWrapper really has no defined meaning with respect to JSON, so I don't know whether this is a bug or feature. More, since changing the behavior would be backwards incompatible, I don't think it can even be changed.

So I am not sure what, if anything, should be done here.

[Vulcannis]

Not sure what you mean about defined meaning; the element wrapper's name is exactly what should be used for the field name in the JSON object. It's only done when the USE_WRAPPER_NAME_AS_PROPERTY_NAME feature is enabled. That's the whole point of that feature.

In this case Jackson is not processing the annotation correctly. It did so in version 1.9, but for version 2 the code that handled this was refactored and missed this case. If anything it is currently backwards incompatible. The old code passed in a default name (determind by the property name, as the annotation dictates), whereas the refactored code just stubs it out with "".

[cowtowncoder]

Ah. Read the description too fast. Yes, with respect to that feature it should work that way.
Is this with 2.2.3?

[Vulcannis]

Gah, I forgot to mention the versions in the initial report. Yes, this is with 2.2.3. The version I tried with correct behaviour was I believe 1.9.2 (shipped with JBoss 7.1.2.)

[cowtowncoder]

Makes sense (wrt versions). This was unintended change between 1.x and 2.x.

[cowtowncoder]

I can reproduce this with 2.3.0-SNAPSHOT

[cowtowncoder]

Fix is now in for 2.3.0; bit ugly, but passes the test I added, and does not break XML module either.