dataFormat and @ServiceMode in camel-cxf: duplication of effort?

[adrian.trenaman]

I have a question on the use of dataFormat in the URI of the camel-cxf component. I note that in our demos, if you want to accept MESSAGE or PAYLOAD data, you?ve got to create an appropriate Provider class annotated with:

@WebServiceProvider()

@ServiceMode(Mode.MESSAGE)

Why do we need the @ServiceMode? It repeats the data that we set in the dataFormat property of the URI... Do we really have to set the data format in both places? I?ve found that I typically need to set the ServiceMode and the dataFormat to the same value, but it?s not clear to me why. If I set them to different values, which one gets precedence?

Any suggestions?

/Ade

[njiang]

The DataFormate of URI is not same with JAXWS API's @ServiceMode.

First, camel-cxf's DataFormat has three value , MESSAGE , PAYLOAD, and POJO. Different DataFormat will lead to different interceptor chains, so we can deal with the CXF message for different purposes.

You can treat the POJO DataFormat as the normal way to use the JAXWS API which is provided by CXF, we don't set up the customer interceptor chains for the CXF endpoint.

The ServiceProvider Demo shows you how to interact with the low level message by using the JAXWS API[1], which is specified by the @ServiceMode and @.

If you are using this API, you don't need to set the DataFormate of camel-cxf endpoint, camel-cxf will use the default one POJO DataFormat for the CXF endpoint.

For you last question about which setting will take effect first. Since the camel-cxf endpoint is created by camel-cxf component, the URI DataFormat will take effect before the @ServiceMode in the SEI.

https://jax-ws.dev.java.net/jax-ws-21-ea1/docs/provider.html

[adrian.trenaman]

Thanks for this! Things are clearer now - thanks! However, I'm still aching from the explosion of possible combinations: I have three options for the dataFormat, the choice of whether to use the SEI or a JAX-WS Provider as the serviceClass, and the choice of Source, SOAPMessage or DataSource as the parameter to the Provider implementation class. All these combinations: my experience has been that some of the combinations work, and some do not.

From my experience, the approaches that do work are:

• If you want XML payload, ase a JAX-WS provider interface as the  'serviceClass', paramaterised with <DOMSource>. Use a ServiceMode of 'PAYLOAD' and omit the dataFormat atribute on the endpoint URI.

• If you want SOAP payload as a DOMSource, use a JAX-WS provider interface as the  'serviceClass', paramaterised with <DOMSource>. Use a ServiceMode of 'MESSAGE' and omit the dataFormat atribute on the endpoint URI.

• If you want SOAP payload as a SOAPMessage, use a JAX-WS provider interface as the  'serviceClass', paramaterised with <SOAPMessage>. Use a ServiceMode of 'MESSAGE' and omit the dataFormat atribute on the endpoint URI.

• If you want POJO (JAXB objects) as payload, use a  JAX-WS service endpoint interface as the 'serviceClass'. Set the dataFormat atribute on the endpoint URI to POJO.