You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Jens <sm...@dzbank.de> on 2011/07/25 18:18:40 UTC
CxfEndpoint data formats
Hi,
is there any way to use different data formats for sending and receiving
messages with a given CXF endpoint?
E.g. if I have a route like
from("queue:...").to(cxf:...).process(...)
I'd like to provide the message for the CXF endpoint in PAYLOAD format but
get the response from the service call as a POJO for further processing.
Alternately, is there an easy way to have PAYLOAD format return valid
(wrapped) XML documents? Unfortunately, the unwrapping that PAYLOAD format
performs (and expects for incoming data) on the message makes it hard to use
standard XML features like XPath or XSLT to process PAYLOAD messages.
Thanks,
Jens
--
View this message in context: http://camel.465427.n5.nabble.com/CxfEndpoint-data-formats-tp4631394p4631394.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CxfEndpoint data formats
Posted by Willem Jiang <wi...@gmail.com>.
On 7/27/11 12:09 AM, Jens wrote:
> Hi Willem.
>
>>> is there any way to use different data formats for sending and receiving
>>> messages with a given CXF endpoint?
>>>
>>> E.g. if I have a route like
>>>
>>> from("queue:...").to(cxf:...).process(...)
>>>
>>> I'd like to provide the message for the CXF endpoint in PAYLOAD format
>>> but
>>> get the response from the service call as a POJO for further processing.
>>
>> If you can extract the request message from the PAYLOAD, you can send
>> the POJO request from the cxf endpoint.
>
> I'm afraid I don't understand what you mean here. Are you talking about
> converting
> the PAYLOAD format (DOM) into JAXB objects so that the CXF endpoint can
> operate in POJO mode?
Yes, you can do it this way, but it could more straight if you are using
POJO data format.
>
> That might work in this particular case but it gets much more cumbersome
> when
> we're talking about MESSAGE vs. POJO, for example. I have a couple of use
> cases
> where source and target (CXF) data formats are different. I take your answer
> to
> mean there is no generic way to switch between different data formats in a
> single
> endpoint, though. Correct?
You may take a look at the camel-soap data format, it leverage the JAXB
to do the converter work. But it doesn't support all the case as CXF does.
>
>>> Alternately, is there an easy way to have PAYLOAD format return valid
>>> (wrapped) XML documents? Unfortunately, the unwrapping that PAYLOAD
>>> format
>>> performs (and expects for incoming data) on the message makes it hard to
>>> use
>>> standard XML features like XPath or XSLT to process PAYLOAD messages.
>>
>> I don't quit understand you question, but can you try to set this
>> wrappedStyle option to be true to see if anything changed.
>
> Wrapped is an overloaded term so maybe I shouldn't have used it here.
>
> Imagine a request like this
>
> [soap:envelope]
> [soap:body]
> [myns:request]
> [myns:param1/]
> [myns:param2/]
> [/myns:request]
> [/soap:body]
> [/soap:envelope]
>
> As a CxfPayload the message will only contain (as a NodeList)
> [myns:param1/]
> [myns:param2/]
>
> That obviously doesn't constitute a valid XML document.
>
> If, instead, it represented the complete SOAP body like this
>
> [myns:request]
> [myns:param1/]
> [myns:param2/]
> [/myns:request]
>
> it would be valid and it would be possible to use XPath etc. to work
> with it. Currently, I use a custom processor to convert the NodeList
> to such a document but it would be nice if there was a way to do this
> out of the box.
The PayLoad body is designed to map the parameter list of the option.
If you want to get the full Document, you may consider to use the
MESSAGE data format.
>
> Regards,
> Jens
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CxfEndpoint-data-formats-tp4631394p4635388.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: CxfEndpoint data formats
Posted by Jens <sm...@dzbank.de>.
Hi Willem.
>> is there any way to use different data formats for sending and receiving
>> messages with a given CXF endpoint?
>>
>> E.g. if I have a route like
>>
>> from("queue:...").to(cxf:...).process(...)
>>
>> I'd like to provide the message for the CXF endpoint in PAYLOAD format
>> but
>> get the response from the service call as a POJO for further processing.
>
> If you can extract the request message from the PAYLOAD, you can send
> the POJO request from the cxf endpoint.
I'm afraid I don't understand what you mean here. Are you talking about
converting
the PAYLOAD format (DOM) into JAXB objects so that the CXF endpoint can
operate in POJO mode?
That might work in this particular case but it gets much more cumbersome
when
we're talking about MESSAGE vs. POJO, for example. I have a couple of use
cases
where source and target (CXF) data formats are different. I take your answer
to
mean there is no generic way to switch between different data formats in a
single
endpoint, though. Correct?
>> Alternately, is there an easy way to have PAYLOAD format return valid
>> (wrapped) XML documents? Unfortunately, the unwrapping that PAYLOAD
>> format
>> performs (and expects for incoming data) on the message makes it hard to
>> use
>> standard XML features like XPath or XSLT to process PAYLOAD messages.
>
> I don't quit understand you question, but can you try to set this
> wrappedStyle option to be true to see if anything changed.
Wrapped is an overloaded term so maybe I shouldn't have used it here.
Imagine a request like this
[soap:envelope]
[soap:body]
[myns:request]
[myns:param1/]
[myns:param2/]
[/myns:request]
[/soap:body]
[/soap:envelope]
As a CxfPayload the message will only contain (as a NodeList)
[myns:param1/]
[myns:param2/]
That obviously doesn't constitute a valid XML document.
If, instead, it represented the complete SOAP body like this
[myns:request]
[myns:param1/]
[myns:param2/]
[/myns:request]
it would be valid and it would be possible to use XPath etc. to work
with it. Currently, I use a custom processor to convert the NodeList
to such a document but it would be nice if there was a way to do this
out of the box.
Regards,
Jens
--
View this message in context: http://camel.465427.n5.nabble.com/CxfEndpoint-data-formats-tp4631394p4635388.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CxfEndpoint data formats
Posted by Willem Jiang <wi...@gmail.com>.
On 7/26/11 12:18 AM, Jens wrote:
> Hi,
>
> is there any way to use different data formats for sending and receiving
> messages with a given CXF endpoint?
>
> E.g. if I have a route like
>
> from("queue:...").to(cxf:...).process(...)
>
> I'd like to provide the message for the CXF endpoint in PAYLOAD format but
> get the response from the service call as a POJO for further processing.
If you can extract the request message from the PAYLOAD, you can send
the POJO request from the cxf endpoint.
>
> Alternately, is there an easy way to have PAYLOAD format return valid
> (wrapped) XML documents? Unfortunately, the unwrapping that PAYLOAD format
> performs (and expects for incoming data) on the message makes it hard to use
> standard XML features like XPath or XSLT to process PAYLOAD messages.
I don't quit understand you question, but can you try to set this
wrappedStyle option to be true to see if anything changed.
Here is the description of the wrappedStyle
"New in 2.5.0 The WSDL style that describes how parameters are
represented in the SOAP body. If the value is false, CXF will chose the
document-literal unwrapped style, If the value is true, CXF will chose
the document-literal wrapped style"
>
> Thanks,
> Jens
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CxfEndpoint-data-formats-tp4631394p4631394.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang