DougBreaux 270007SMYJ Visits (8995)
JAXB and Boolean
It turns out that by default, JAXB 2.2, the level in Java 7, generates the wrong kinds of getters for Boolean (wrapper object) fields. It generates isXXX() getters instead of getXXX() getters. And according to the JavaBeans spec, only boolean primitives are supposed to do that.
The fix is to use a JAXB compiler option, "-en
In the JAX-WS <wsimport> Ant task, it looks like this:
<target name="wsimport"> <wsimport sour
This causes getXXX() methods to be generated instead of isXXX() methods. (I found myself thinking it would be nice if both styles of getters were produced, but I admit I don't know if that would violate some other specification or convention.)
xs:boolean with minOccurs="0"
Related is the fact that, with this version of JAXB, XML schema types that have minOccurs=0 get generated as "wrapper" classes (e.g. Boolean) instead of primitives (boolean). This is so that the value can be null if the XML element is missing or empty.
Based on some non-null-safe legacy code that I'm migrating, it *seems* that earlier versions of JAXB behaved differently, at least under WebSphere 6.1: either using primitives or otherwise returning a default value on empty.
A different issue we saw with JAX-WS/JAXB under WAS 8.5.5/Java7, was that xs:string values with xsi:nil="true", were sometimes returning null rather than empty string. (Specifically, on the second and subsequent unmarshals. See forum thread.)
WebSphere 8.5.5 has an optimization option, com.
JAX-WS 2.2 is the latest version, and it's supported by WebSphere 8.5. However, it appears to sort-of want Java 7.
wsimport can either be run as a script or from Ant.
The script is part of the SDK now, even included with J2SE. The
The Ant task is actually provided by Sun classes, but they are included in WebSphere's jars as well. The
The jars required to run the Ant task are found in the WebS
If you want to try JAX-WS 2.2. under Java 6, you also need from the WebS
Create an Ant taskdef like this:
<!-- Ant task definition for wsimport -->
A sample <wsimport> task looks like this:
References and Articles
Edit: Update for newer WebSphere fixpacks
A colleague discovered that with the latest copies of the two "plugins" jars, the wsimport task no longer works. Sure enough, com.
Instead, however, the class com.