DougBreaux 270007SMYJ Visits (5727)
Minor addition to Spri
While my earlier-mentioned API supports both JSON and XML, the XML is more legacy, and I hadn't tested all cases with it yet. Further testing revealed that my previous multi-error pattern was too simplistic for XML responses:
List<ErrorResponse> errors = new ArrayList<>();
for (FieldError f: e.g
(Note that's slightly different from my earlier version, I switched the ErrorResponse to use 2 Strings instead of int/String.)
JSON was fine, but "Accept: application/xml" calls were receiving 406 Not Acceptable when errors were returned.
My first thought/fear was that the above Spring @ExceptionHandler approach wasn't going to be smart enough to send the correct response type, based on the caller's "Accept" Request header.
But it turned out it was the much simpler issue that List isn't sufficient to have JAXB serialize out appropriate XML. I really should have remembered this from earlier JAXB endeavors.
(Observation: Spring MVC really is powerful at figuring things out and allowing simple coding patterns.)
The simple solution (with thanks to StackOverflow Why
With the above @ExceptionHandler method modified to:
ErrorList errors = new ErrorList();
for (FieldError f: e.ge
Which produces either the original JSON or the following XML:
No more 406 HTTP response error code.
DougBreaux 270007SMYJ Visits (10257)
Little tip when generating JAXB classes from XML Schema:
This after I got the error:
Example of #3, with a generic method so it can be used for multiple types:
private <T> T unma
Source s = new Stre
DougBreaux 270007SMYJ Visits (6943)
While that second link really contains all the crucial information on those issues, I thought I'd also post it here.
WebSphere Liberty Core(?)
First, my RAD install came with an installation of WebSphere Liberty, I think "Core" Edition. (Liberty Features compares the Editions.)
And that didn't come with very many Features to enable. I didn't notice this until I went to generate JAXB Java classes from an XML Schema (XSD) file. Where I got the error:
Errors occurred during wsgen.
(Interesting, didn't even know I was using wsgen, eh?)
Well, that is the correct location of my Liberty install. But, hey, there is no jaxb folder there at all. I have a couple of other xjc instances on the system, but I have no idea how to make RAD use them. My project is a Web Project, pointed at a JRE that does have xjc, and the Liberty Runtime, but apparently that's not sufficient for the RAD configuration to connect the dots.
Liberty for Developers
So instead I uninstalled that copy of Liberty (with Installation Manager), and then added to Installation Manger the "IBM WebSphere Application Server Liberty for Developers (ILAN)" repository, from WebS
The ILAN versions are available for free with a DeveloperWorks ID and have the caveat:
This one let me install all kinds of Features, including ... JAXB support. Now the xjc tool is there where RAD wanted it.
"jar" access is not allowed
Except, now RAD generating JAXB from Schema produced the following error:
The xjc tool returned an error:
Also, it turns out I only got this message if I elected for the code-generation process to create Serializable classes. If I didn't select that option, the generation succeeded. Weird since I the only difference I noticed - after I got it working - is adding "implements Serializable" to the generated classes.
In any case, this StackOverflow link pointed at a very similar problem, with a definitely non-intuitive workaround, that eventually succeeded when I found the right place for it:
For me, this meant going to the /opt
# ... because "jar" access is not allowed"
Update: Not just Mac + Liberty
Now back on my primary Windows 10, with WebSphere 8.5.5 Full Profile, I had the same problem occur:
The Xjc tool has completed Web service artifact generation.
Same fix/workaround, this time in C:/Program Files (x86
(And yes, this seems to me like a bug in either RAD/WDT, or WebSphere, or the combination.)
DougBreaux 270007SMYJ Visits (16928)
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.