cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Generated code with minOccurs="0" and nillable="true" contains JAXBElement
Date Tue, 02 Dec 2008 21:51:07 GMT
On Wednesday 26 November 2008 5:09:17 pm Steve Cohen wrote:
> 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?

It's not so much a configuration file as a jaxb binding file.   The command 
line tools take a -b flag that can specify a jaxb binding file (or jaxws 
customization file) that provides customizations.     Someone please correct 
me if I'm wrong (not really a strong point), but I think the file would look 
something like:

<jaxb:bindings 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    jaxb:version="2.0">

    <jaxb:globalBindings generateElementProperty="false"/>

</jaxb:bindings>

Dan

>
> 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?



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message