search

mklemm / jaxb-rich-contract-plugin

Implements some JAXB plugins to generate advanced contract scenarios from XSD
MIT License
67 stars 33 forks source link

Add support for JAXBElement fields in the Fluent API #31

Closed terje2001 closed 7 years ago

terje2001 commented 7 years ago

JAXB creates quite unnatural code when fields may be 'nil' by wrapping them in JAXBElements. One must then use the (also generated) ObjectFactory to create the right field values.

This Pull Request tries to help by detecting fields with JAXBElement and adding a extra withXxX(SomeType) method that automatically uses ObjectFactory to wrap supplied simple type. This gives the user an option of using a very much simplified syntax that will be much more intuitive.

I hacked this out very quickly today and works well on the WSDL i have at hand, all comments welcome.

mklemm commented 7 years ago

Hi terje, could you please supply an example XSD that shows the behavior you described? To my experience, simply putting "nillable='true'" into an element definition doesn't cause the element to be generated as JAXBElement... There might be a certain combination of type of the element, nillability, and maybe other factors...

terje2001 commented 7 years ago

Hi Mirko,

Yes, you are correct, I am missing some additional details. In addition, the field needs to be optional.

This discussion has a good example and shows the current set of options: http://stackoverflow.com/questions/26549095/jaxb-xjc-generates-jaxbelementstring-rather-than-just-string-to-handle-null-c

In my case, the tri-state of these fields (set to a value, not present or set to nil) is used for update operations of a large data set over soap. Having optional with nillable allows the caller to ignore fields that we do not want to change (no present) or possible unset fields back to default (set to nil).

So, clients of such structures have (currently) two options: Use JAXBElement everywhere, producing horrible code. Or, set "generateElementProperty" to true in the binding file. The latter causes every field to be marshalled every time with nil=true, which will not work for me.

mklemm commented 7 years ago

OK, I'll merge the pull request, but I think we have to make it clear what happens if you use the withXXX-Methods to set the field to null. Will it generate a JAXBElement with a value of xsi:nil or will it set the field holding the JAXBElement to null (meaning "element not present")? Especially, in your use case, this is an important distinction...