camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <>
Subject Re: Modifying SOAP:Fault errors raised by endpoints
Date Sat, 13 Mar 2010 07:27:10 GMT

I still have no idea how the TypeConverter is being called, but it's 
working great :).

I can make my SOAP:Fault converter into an interceptor, which has the 
benefit of making the routes simpler and thus more understandable by my 
However if I do so the Tracer (using JPA) does not record the altered 
I have got tracer.setTraceInterceptors( true ); but that doesn't seem to 
make any difference, neither does the order in which the interceptors 
are added.
Is it possible to make the Tracer record the output from another 
If it isn't I'll just log the change myself.

When the Tracer logs an exception it's just using toString, which misses 
out on a lot of information in a soap:fault.
I tried writing a TypeConverter for 
org.apache.cxf.binding.soap.SoapFault, but that's not being called.
Is there a way to make the Tracer use a TypeConverter for logging 


On 10/03/2010 00:41, Willem Jiang wrote:
> Hi Jim,
> I'm already committed a patch[1] for the issue, and I just change the 
> CxfPayLoad class's toString() method.
> If you want to do some customer change on that , you just need to add 
> TypeConverter[2] to turn the CxfPayLoad object into String.
> [1]
> [2]
> Willem
> Jim Talbut wrote:
>> Thanks Willem.
>> Whilst that change will solve my particular problem, wouldn't it be 
>> better to have a more generic way to specify how the message should 
>> be formatted?
>> Something like the equivalent of the formatter that can be passed in 
>> for the log messages?
>> I'm happy to have a look at doing a patch to enable this.
>> Jim
>> On 09/03/2010 01:32, Willem Jiang wrote:
>>> Hi Jim,
>>> It should be easy to implement your requirement by adding a type 
>>> converter which can help use turn the List<Element> into a String.
>>> I filled a JIRA[1] for it.
>>> [1]
>>> Willem
>>> Jim Talbut wrote:
>>>> Thank Willem,
>>>> The first problem I've found with using PAYLOAD is that the Tracer 
>>>> (which I was using with JPA) is no longer logging the full message 
>>>> contents.
>>>> This is because it calls toString on the inbound message, but that 
>>>> is now a CxfPayload, which contains a List<Element> and 
>>>> Element.toString() does not walk the DOM.
>>>> Is the best approach for resolving this to simply replicate the 
>>>> functionality of Tracer in my own classes?
>>>> Jim
>>>> On 08/03/2010 02:53, Willem Jiang wrote:
>>>>> Hi Jim,
>>>>> In MESSAGE DataFormat, camel-cxf endpoint will not read the 
>>>>> Message detail information, it just redirect the input stream.
>>>>> PAYLOAD and POJO DataFormat will give you the exception that you 
>>>>> want.
>>>>> Willem
>>>>> Jim Talbut wrote:
>>>>>> On 07/03/2010 20:08, Jim Talbut wrote:
>>>>>>> exchange.getIn().On 07/03/2010 07:05, Claus Ibsen wrote:
>>>>>>>> Hi
>>>>>>>> You can enable the soapFault=true on the CamelContext which
>>>>>>>> faults into exceptions.
>>>>>>>> Or you can simply add a processor step at the end of your

>>>>>>>> route, and
>>>>>>>> check if the exchange is a fault
>>>>>>>> public void process(Exchange exchange) {
>>>>>>>> boolean isFault = exchange.hasOut()&&  
>>>>>>>> exchange.getOut().isFault();
>>>>>>>> // do something before the OUT message is returned to the
>>>>>>>> }
>>>>>>> Putting on the extra process step works (I didn't know you could

>>>>>>> do that, I'd assumed that InOut routes were stack-like, but I

>>>>>>> guess they're actually more like a loop given that they end up

>>>>>>> back at the source from).
>>>>>>> But neither context.setHandleFault(true) nor 
>>>>>>> from("xxx").handleFault().to("yyy") work - my onException is

>>>>>>> never called and the soap:fault is returned to the client.
>>>>>>> I think the problem is that the CXF transport isn't setting it

>>>>>>> as a fault.
>>>>>> Ah!
>>>>>> My apologies for requiring you to engage psychic debugging (the 
>>>>>> problem with being new to something is that you don't know what 
>>>>>> is important).
>>>>>> The problem was that I was working in with DataFormat.MESSAGE - 
>>>>>> and I presume that means I'm taking on more responsibility than I

>>>>>> want to.
>>>>>> A change to PAYLOAD should be adequate for my needs and now I get

>>>>>> an exception.
>>>>>> Might be worth a note on the Camel CXF page to explain that 
>>>>>> difference.
>>>>>> Thanks very much for your help.
>>>>>> Jim

View raw message