Hi,
You could do the same thing to the out message as you do for in message.
Here are the routing rule example
form("cxf:bean:routerBean")
.processor(new InMessageProcessor())
// processor of the inbound message
.to("cxf:bean:serviceBean")
.process(new OutMessageProcessor())
// processor of the outbound message
// Note: The in message that get in the OutMessageProcessor in a copy of
the out message which get from the cxf:bean:serviceBean's endpoint.
Willem
[email protected] wrote:
> Hi Willem,
>
> unfortunatly, this does not work too due to project requirements. Here're
> some more details of my requirements and what I tried so far.
>
> The requirement is the delete all SOAP Headers in the SOAP message on the way
> from inbound request to outbound request after they are verified by some
> handlers.
>
> I tried to put the data format to MESSAGE on the inbound side and I could get
> the message as a string. That was easy to handle. But after the processor was
> called, an "cannot find operation name" exception was thrown. So I guessed
> that's maybe because the inbound side just passes the XML stream (because
> configured to be MESSAGE) instead of creating a cxf message (and so no cxf
> header operation name was set). What I tried then was to configure the
> outbound endpoint to be of data format MESSAGE too, and this time it worked
> fine. So far so good.
>
> But another requirement is that the response on the outbound side has to some
> enhancement on the SOAP Header side. These enhancements are currently
> implemented by custom handlers and interceptors. But these handlers and
> interceptors are ignored, if response outbound side is configured to be of
> format MESSAGE.
>
> Here's an overview:
>
> client request => inbound camel (verify some SOAP header fields) =>
> myProcessor(remove all SOAP headers) => outbound camel => server
> client response <= outbound camel (add some SOAP header values, sign the
> response) <= inbound camel response <= server response
>
> The processor is a pipeline processor is not called on response.
>
> Do you have any idea how to implement the processor and assure that all
> handlers/interceptors are called ? I thought, converting it to a document
> would be easy (since string manipulation is no option, see above).
>
> Best regards,
> Mario
>
> willem.jiang wrote:
>> Hi,
>>
>> If you let the CXF endpoint work in POJO format, I don't think it is
>> easy to turn the CxfMessage into a Document.
>> Maybe you should try to use MESSAGE data formate (the message body is a
>> instance of InputStream), camel'sXmlConverter can turn a InputStream
>> into a Document.
>>
>> Willem
>>
>> mario_horny wrote:
>>> Hi all,
>>>
>>> I want to implement a custom processor that modifies a CxfMEssage routed
>>> in
>>> POJO format.
>>>
>>> How can I get the CxfMessage as a w3c Document ? Is there a converter
>>> available ? If so, could someone provide me a snipped that shows how
>>> this
>>> converter is registered (or made "ready to use") ?
>>>
>>> Best regards,
>>> Mario
>>
>>
> Quoted from:
> http://www.nabble.com/Re%3A-need-CxfMEssage-%3D%3E-w3c.Document-converter-tp22247048p22247048.html
>
>
