• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JAXB - XSD to Java Object conversion

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have two elements mentioned in XSD as

one with minOccurs="0" nillable="true" and other one minOccurs="1" nillable="true"

I am creating java classes using XJC command. In the ObjectFactory, QName is created for minOccurs="0" nillable="true" element but not for others. Also related JAXBElement create function. What's the logic behind it?

Similarly when I exposed a webservice using this, in referred XSD of WSDL this objects types are referred as type="xs:anySimpleType" as it's referred as @XmlElementRef(name = "description", namespace = "http://com.poc/types", type = JAXBElement.class) in JAXB created classes. What's the idea behind it?
 
Ranch Hand
Posts: 734
7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a bit of an obscure corner of the jaxb and of the use of XMLSchema-instance namespace as well I must say.

To begin with, it is clear that
<parent>......</parent>
and
<parent>...<x />...</parent>
and
<parent>...<x xsi:nil="true" />...</parent>
are not the same thing.

The nillable="true" in the xsd effectively does two things: first it extends the scope of validity of the element qualified by it by allowing dynamically of null content for an instance eventually submitted for validating overriding whatever type it is defined in the static schema. The second thing is that when it actually is of null content allowing that information be preserved under the various operations the instance might be subjected to as long as the object model of binding is the one generated by schema compilation without specific customization effectively making it uneffective.

This description sounds cryptic if not paying all the attention needed and I have tried to be quite exact.

Now, a problem arises out of it. It is the case when an element is decorated by a cardinal fact of minOccurs="0" as well as nillable="true" in the schema. If the element is mapped to an object bare (an xs:string type to a field of some class of type String, or an xs:anyType to an Object in general...) there is a problem to face up.

If a field or an object in the object model be null with annotation @XmlElement or alike, it would normally not be marshalled out leaving it absent in the serialized form (the xml document). But for those having the facet minOccurs="0", the field/object is being optional. It is ambiguous to its meaning whether it is taking advantage of it being optional, or that the author means to take advantage of the mechanism of type overriding in the instance. That is why xsi:nil="true" to show unambiguously, if presence, it is the latter intention. This is the unmarshalling aspect of it coupling with the xml binding technology.

How about the marshalling aspect of it in the xml binding technology? What if the author of the object model want to make it presence in its serialization (xml document) showing its intention of that overriding degree of freedom (hence, a vaidator might come into play as well)? And consequently also have its presence in the serialized form.

That is why the JAXB team comes up with the device of having the JAXBElement as a wrapper to the element in question. In that case, an instance of JAXBElement<T> can be initialized by its "value" (4th argument in its constructor, which can be null) or it can be itself null uninitialized. In that case, the marshalling/unmarshalling has always JAXBElement<T> either itself null (meaning the element x is absent at all) or if it is non null, but its "value" can be null (meaning <x xsi:nil="true" />), the ambiguity is covered and can be preserved in all sort of operations it would be subjected to.

An insistence on the preservation of info in general or a preservation of info in a round-trip marshalling-unmarshalling-marshalling cycle is a big deal here, and is the leading idea on the whole thing.

The building block is further acquiring even more concrete significance when the whole binding technology is beefed up with validation requirement.

Perhaps I can point you to the customization of un-playing it, namely a customization with xjc:generateElementProperty false so that you can contrast the whole thing in the opposite perspective to gain more sense of it one way or another. You can check out the wsit area, such as this.
http://docs.oracle.com/cd/E19159-01/820-1072/ahiid/index.html

I am not surprised one can be (more) at a lost after reading the above. That is best I can come up improvising spontaneously without too much re-reading to iron out the angular points of deduction. No gurantee.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic