On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut <jtal...@spudsoft.co.uk> wrote: > Willem, > > Ah. > 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 > clients. > However if I do so the Tracer (using JPA) does not record the altered > SOAP:fault. > 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 > interceptor? > 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 > exceptions? >
You can implement your own org.apache.camel.processor.interceptor.TraceFormatter and format the traced message exactly how you like it. And to use it just add it to the Registry, eg in Spring XML just add a <bean id="myFormatter" class="xxxx.MyTraceFormatter"/> And Camel should pick it up and use it instead of the DefaultTraceFormatter See using customer formatter http://camel.apache.org/tracer > Thanks > > > 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]http://svn.apache.org/viewvc?rev=920708&view=rev >> [2]http://camel.apache.org/type-converter.html >> >> 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]https://issues.apache.org/activemq/browse/CAMEL-2531 >>>> >>>> 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 turns >>>>>>>>> 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 caller >>>>>>>>> } >>>>>>>> >>>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
