DougBreaux 270007SMYJ Visits (5819)
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.
HTML comments are not displayed by a user's browser, but they're available in the source view. JSP comments are removed before the source HTML is returned to the browser.
In many cases where we use comments in our JSPs, we prefer they not appear in the browser-viewable page source. Best case, they're confusing and useless to anybody who looks at them. Worst case, they actually reveal something about our implementation which we'd rather not reveal.
So without further ado:
<!-- HTML Comment -->
DougBreaux 270007SMYJ Visits (5568)
An oldie, but still useful from time to time.
Ever wonder which Jar or directory contains a class you're using in your JEE Web Application? Or which of multiple provider Jar files is the one being used? Or even whether or not a particular class is found at all?
No need to actually include it in your Web App permanently, but easy to deploy manually if you ever need it.