compatibility issue with JAXB 2.0

[Tomas-Kraus]

The attached test case works with JAXB 2.0, for example with JDK 6 update 1.
The test case is broken when running with JDK 6 update 4 (JAXB 2.1).

see also forum entry:
http://forums.java.net/jive/thread.jspa?threadID=36902&tstart=75

Environment

Operating System: All
Platform: All

Affected Versions

[2.1.1]

[Tomas-Kraus]

@glassfishrobot Commented
Reported by brands

[Tomas-Kraus]

@glassfishrobot Commented
Was assigned to snajper

[Tomas-Kraus]

@glassfishrobot Commented
brands said:
Created an attachment (id=245)
junit test case

[Tomas-Kraus]

@glassfishrobot Commented
File: jaxbtest.zip
Attached By: brands

[Tomas-Kraus]

@glassfishrobot Commented
dharland said:
In our code i noticed that some of our list-based XML unit tests were still
passing. It looks like those that began failing w/ JDK 1.6.0 build 04 deal with
lists whose elements are polymorphic. I have created simplified examples of the
2 basic ways i've dealt w/ such lists and will attach them. If you run them
under JDK 1.6.0 build 02, they should work properly. Under build 04 the
setXxx(List xxx) methods are never called.

[Tomas-Kraus]

@glassfishrobot Commented
dharland said:
Created an attachment (id=248)
Two simplified test cases

[Tomas-Kraus]

@glassfishrobot Commented
File: listTrouble.tar.gz
Attached By: dharland

[Tomas-Kraus]

@glassfishrobot Commented
dharland said:
Minor correction to my comments of Mar 26: where i said "build" the proper term
is "update", as in "update 04".

[Tomas-Kraus]

@glassfishrobot Commented
dharland said:
WORK-AROUND AVAILABLE

My previous diagnosis of polymorphic vs monomorphic was incorrect. As noted in
the forum and in a previously attached example, the setXxx(List xxx) method
is never called in JAXB 2.1.x, whereas it had been called in 2.0.x, and this is
true regardless of the type of object held in the collection.

It looks like JAXB is calling the the getter even when unmarshalling XML into
objects and completely ignoring the setter. That means JAXB is making an
assumption that the getter returns the actual collection instance variable, and
this is a poor assumption to make. An extremely common, and defensive, pattern
for objects that hold collections is:

private List bars;

@XmlElementWrapper
@xmlelement(name="bar")
public List getBars()

{ return new ArrayList(bars); }

We can work around this – w/out losing the ability to hide the real collection
from clients – by making a private method for JAXB's use that returns the real
collection, ala

@XmlElementWrapper(name="bars")
@xmlelement(name="bar")
private List getXmlBars()

{ return bars; }

...and removing the xml annotations from the public getBars method.

Even though we can work around the problem, i think the change from 2.0.x to
2.1.x that resulted in not calling setters for collections was a bad one.

In case the above was not clear, i'll attach another example in a minute.

[Tomas-Kraus]

@glassfishrobot Commented
dharland said:
Created an attachment (id=252)
Shows work-around; clarifies the problem

[Tomas-Kraus]

@glassfishrobot Commented
File: workAround.tar.gz
Attached By: dharland

[Tomas-Kraus]

@glassfishrobot Commented
dharland said:
Created an attachment (id=253)
USE IN PLACE OF PREVIOUS ATT. Shows work-around; clarifies the problem

[Tomas-Kraus]

@glassfishrobot Commented
File: workAround.tar.gz
Attached By: dharland

[Tomas-Kraus]

@glassfishrobot Commented
@pavelbucek said:
fixed in trunk

[Tomas-Kraus]

@glassfishrobot Commented
alexkos said:
Pavel,
would you please provide more details about the fix, e.g. does it address all
collections or just lists (I have had the same issue with sets), will JAXB
completely switch back to using collection setters or will there be some
hierarchy of choices (if the setter is not available). I am trying to figure out
if my workaround that relies on JAXB directly manipulating the collection
acquired via the collection getter will break as soon as I switch to the fixed
version of JAXB. Thanks. -Alex

[Tomas-Kraus]

@glassfishrobot Commented
@pavelbucek said:
Hi Alex,

your workaround won't break - I've only added set invocation after parsing whole
List/Set (any collection).

So whole process starts with invoking get and "clearing" result (as previously)
or creating new instance of collection (when getter returns null). After parsing
all collection items (and adding them to collection) set method is invoked (if
exists).

Pavel

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
Note that this was a change against spec - thus we shall add a switch to unmarshaller to allow both
behaviours.

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
assigning to pavel

[Tomas-Kraus]

@glassfishrobot Commented
@pavelbucek said:
updating target milestone

[Tomas-Kraus]

@glassfishrobot Commented
@pavelbucek said:
metro2.1-waived

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
The fix is in 2.2 codebase, marking as such.

[Tomas-Kraus]

@glassfishrobot Commented
snajper said:
Reopening to implement switch as I mentioned already as the default behaviour does not conform to spec.

[Tomas-Kraus]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAXB-488

[Tomas-Kraus]

• Issue Imported From: compatibility issue with JAXB 2.0 javaee/jaxb-v2#488
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot