cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [JiBX DataBinding] Question on handling Simple Types
Date Fri, 18 Jun 2010 02:33:21 GMT

Well, another option to consider (I'm not saying this is the way to go, just 
something to consider.  I don't even know if this is possible with JIBX) is 
how the JAXWS/JAXB code handles this....

With JAX-WS/JAXB, it uses ASM to generate, in memory, classes for the wrapper 
element which contains all the JAXB annotations and such necessary to 
completely read/write the entire message body.   There is then a WrapperHelper 
to pull the individual params out of that object.   Thus, JAXB doesn't see the 
<arg0>Alice</arg0>, it sees the entire message as a structure.

Right now, the creation of the wrapper beans is done in the JAX-WS frontend, 
but I could definitely see pushing that into the JAXB databinding and allow 
other databindings to do the same.   If you think it's possible with JIBX, 
it's something we could look into more.

The other option would be to just handle it yourself.   Get the element text, 
you know the Class, since it would just be the primitives, the number of cases 
you need to handle is pretty small and most of the code is probably already in 
Aegis someplace.


On Thursday 17 June 2010 8:58:36 pm Nilupa Bandara wrote:
> Hi,
> Consider the following Java class which provides simple echoString service.
> public interface EchoService {
>     String echoString(String content);
> }
> I exposed it as a Web service using the following code.
> EchoServiceImpl echoServiceImpl = new EchoServiceImpl();
> ServerFactoryBean svrFactory = new ServerFactoryBean();
> svrFactory.setServiceClass(EchoService.class);
> svrFactory.setAddress("http://localhost:8080/EchoService");
> svrFactory.setServiceBean(echoServiceImpl);
> svrFactory.getServiceFactory().setDataBinding(new JiBXDataBinding());
> svrFactory.create();
> It produces the correct output for the following input.
> <soap:Envelope xmlns:soap="">
>    <soap:Body>
>       <ns1:echoString xmlns:ns1="">
>          <ns1:arg0>Alice</ns1:arg0>
>       </ns1:echoString>
>    </soap:Body>
> </soap:Envelope>
> My question is the following.
> When the CXF framework receives the message, it invokes the JiBXDataReader
> to unmarshall  xml content which is "<ns1:arg0>Alice</ns1:arg0>".  However
> it seems that I can't unmarshall it using
> unmarshallingContext.unmarshallElement(..) method since UnmarhallingContext
> can't be obtained for "<ns1:arg0>Alice</ns1:arg0>". That is because
> "<ns1:arg0>Alice</ns1:arg0>" element doesn't corresponds to a Java classes
> compiled with binding info. One work around would be to use
> the JibxNullBindingFactory[2]  to imitate the IBindingFactory interface for
> simple types.
> So should we proceed with the above workaround /  Is there a better way of
> doing it? Or should we completely ignore above case and support only the
> exposure of Java beans compiled with binding information. (i.e. the
> echoString method should be change to something like  Output
> echoString(Input) where both Input, Output are Java beans compiled with
> binding information. Input, Output act as wrapper classes for the string
> content going to-and-from)
> Any thoughts ?
> Nilupa
> [1] Updated JiBX DataBinding implementation code is available at :
> [2]
> rg/apache/xcf/jibx/

Daniel Kulp

View raw message