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.
Dan
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="http://schemas.xmlsoap.org/soap/envelope/";>
> <soap:Body>
> <ns1:echoString xmlns:ns1="http://simple_types.jibx.xcf.apache.org/";>
> <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 :
> http://github.com/nilupa/cxf/tree/trunk/rt/databinding/jibx/
> [2]
> http://github.com/nilupa/cxf/blob/trunk/rt/databinding/jibx/src/main/java/o
> rg/apache/xcf/jibx/JibxNullBindingFactory.java
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
