I think this may be the answer to a question I posed the other day as well:
http://www.nabble.com/cxf-java-code-generation-question-td20661806.html
Let me therefore make sure I understand your suggestion:
Are you suggesting that if I switch to CXF 2.1.3 there is some
configuration file
where I can enter the line
<jaxb:globalBindings generateElementProperty="false"/>
and this will get rid of the JAXBElements. I see that Thomas S. has
confirmed that this
works. Can you tell what configuration file to put this in?
Thanks.
Daniel Kulp wrote:
On Wednesday 26 November 2008 12:10:20 pm Thomas S. wrote:
I'm using CXF (Version 2.1.3) to generate client stubs for the google
adwords api from their wsdl.
Especially I use the maven cxf-codegen-plugin and JAXB for data binding.
After some time of trial and error almost everything is working fine now!
But one thing is very annoying: The occurence of JAXBElement classes within
the client method signatures! This forces you to write more code while
using the client stub, and (even worse!) you have to know about XML
specific stuff like a QName or xsd:nill!
Well, you don't really need to deal with the QNames. There are "factory
methods" on the ObjectFactory that would create the JAXBElement things from
the String's and such. Thus, you could call them. Still a bit of an
annoyance.
Let me give an example. Let this be a type description within the wsdl:
I'm aware, that an element marked both nillable="true" and minOccurs="0"
forces JAXB to generate code that makes it possible to distinguish between
"no element" and "element value is null", so it's hardly possible to use an
String object for attribute a. For b and c an object of class String works
perfecly, cause the are either nillable (c) or must not occure (b).
But now I'm wondering, why the example code from google, which uses client
stubs generated with Axis 1.2.1 and is based on the same wsdl, uses objects
of class String, Long and Integer in such situations!
Because Axis code generators aren't anywhere close to standards compliant.
Actuall, Axis 1.2.1 is very old and closer to JAX-RPC which has completely
different guidelines as well.
So is there some way to get rid of these JAXBElements?
I have no idea. You will need to ask on the JAXB list:
http://jaxb.dev.java.net
Actually, while googling this, I discovered in 2.1, they added a some binding
customizations for it. :
generateElementProperty false
So
<jaxb:globalBindings generateElementProperty="false"/>
I'm almost sure, that google will not differ between nill of null on server
side, so maybe it's worth to think about some kind of flag to let CXF
remove the nillable="true" or minOccurs="0" attribute from XML element, if
both are existing, perhaps in the scope of one wsdl file?
Interesting idea, but if the above works, it may not be necessary.
Dan
Yes, I know this isn't very accurate, but it gives you a much simpler
client stub, and I would prefer this right here!
You may argue, that this is an imprecision within googles wsdl, and I will
totally agree! But actually I have to live with this fault, cause I'm also
not happy to copy googles wsdl and fix it in my local copy. And maybe there
are other wsdls out there containing the same issue!
What do you think?
