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?



-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Reply via email to