You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Jim Talbut <jt...@spudsoft.co.uk> on 2010/03/06 16:51:40 UTC
Modifying SOAP:Fault errors raised by endpoints
Hi,
I have a route that looks like this:
from( sourceEndpoint )
.onException( java.lang.Throwable.class
).process( new Processor() {
public void process(Exchange exchange)
throws Exception
{
log.warn( "onException\n\n\n\n" );
Throwable caused =
exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Throwable.class);
log.info( "caused = " +
caused.getClass().getCanonicalName() );
log.info( "caused = " +
caused.getMessage() );
log.info( "caused = " +
caused.toString() );
log.info( "caused = " + caused );
}
}).end()
.to( destinationEndpoint );
Both sourceEndpoint and destinationEndpoint are CXF endpoints.
When destinationEndpoint is unavailable (the server is down) the
onException handler is thrown correctly.
But if destinationEndpoint returns a SOAP:Fault onException isn't
triggered and I can't find out how to modify the SOAP:Fault that the
clients of sourceEndpoint receive.
I need to ensure that SOAP:Server faults are modified before being
returned to the client.
I tried adding a processor, but that only gets called on the way In,
whether it returns a fault or not.
I'm new to camel but I've managed to get most of my requirements met,
leaving me with just this problem that's got me completely stumped.
Thanks
Jim
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi,
if you are using the Camel transport for CXF then I have an idea what
the problem could be. By default the cxf transport for camel does not
handle faults as exceptions.
You have to manually add a CamelTransportFactory and configure it like
described in http://camel.apache.org/camel-transport-for-cxf.html .
The important setting is the property checkException only if this is
true the EXCEPTION_CAUGHT will be set.
Also see https://issues.apache.org/activemq/browse/CAMEL-2128
Greetings
Christian
Am 06.03.2010 16:51, schrieb Jim Talbut:
> Hi,
>
> I have a route that looks like this:
> from( sourceEndpoint )
> .onException( java.lang.Throwable.class
> ).process( new Processor() {
> public void process(Exchange exchange)
> throws Exception
> {
> log.warn( "onException\n\n\n\n" );
> Throwable caused =
> exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Throwable.class);
> log.info( "caused = " +
> caused.getClass().getCanonicalName() );
> log.info( "caused = " +
> caused.getMessage() );
> log.info( "caused = " +
> caused.toString() );
> log.info( "caused = " + caused );
> }
> }).end()
> .to( destinationEndpoint );
>
> Both sourceEndpoint and destinationEndpoint are CXF endpoints.
> When destinationEndpoint is unavailable (the server is down) the
> onException handler is thrown correctly.
>
> But if destinationEndpoint returns a SOAP:Fault onException isn't
> triggered and I can't find out how to modify the SOAP:Fault that the
> clients of sourceEndpoint receive.
> I need to ensure that SOAP:Server faults are modified before being
> returned to the client.
>
> I tried adding a processor, but that only gets called on the way In,
> whether it returns a fault or not.
>
> I'm new to camel but I've managed to get most of my requirements met,
> leaving me with just this problem that's got me completely stumped.
>
> Thanks
>
> Jim
>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
Yeah
See void setHandleFault(Boolean handleFault);
on RuntimeConfiguration which CamelContext extends.
So you can do in a Java DSL route builder
context.setHandleFault(true);
from("direct:start").to("log:foo").to("log:bar").to("mock:result");
Or you can enable it on a per route basis
from("xxx").handleFault().to("yyy");
On Sun, Mar 7, 2010 at 12:37 PM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Claus,
>
> I didn't find there is a soapFault option int he CamelContext or cxfEndpoint
> URI.
>
> BTW,
> There is HandleFault InterceptStrategy, which could be used to turn a fault
> message into a exception.
> Here is the DSL for configure it
> public void configure() throws Exception {
> HandleFault handleFault =new HaneleFault();
> getContext().addInterceptStrategy(handleFault);
> ...
> }
>
> Willem
>
> 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
>> }
>>
>>
>> On Sat, Mar 6, 2010 at 4:51 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
>>>
>>> Hi,
>>>
>>> I have a route that looks like this:
>>> from( sourceEndpoint )
>>> .onException( java.lang.Throwable.class ).process(
>>> new Processor() {
>>> public void process(Exchange exchange)
>>> throws
>>> Exception
>>> {
>>> log.warn( "onException\n\n\n\n" );
>>> Throwable caused =
>>> exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Throwable.class);
>>> log.info( "caused = " +
>>> caused.getClass().getCanonicalName() );
>>> log.info( "caused = " +
>>> caused.getMessage() );
>>> log.info( "caused = " +
>>> caused.toString()
>>> );
>>> log.info( "caused = " + caused );
>>> }
>>> }).end()
>>> .to( destinationEndpoint );
>>>
>>> Both sourceEndpoint and destinationEndpoint are CXF endpoints.
>>> When destinationEndpoint is unavailable (the server is down) the
>>> onException
>>> handler is thrown correctly.
>>>
>>> But if destinationEndpoint returns a SOAP:Fault onException isn't
>>> triggered
>>> and I can't find out how to modify the SOAP:Fault that the clients of
>>> sourceEndpoint receive.
>>> I need to ensure that SOAP:Server faults are modified before being
>>> returned
>>> to the client.
>>>
>>> I tried adding a processor, but that only gets called on the way In,
>>> whether
>>> it returns a fault or not.
>>>
>>> I'm new to camel but I've managed to get most of my requirements met,
>>> leaving me with just this problem that's got me completely stumped.
>>>
>>> Thanks
>>>
>>> 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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus,
I didn't find there is a soapFault option int he CamelContext or
cxfEndpoint URI.
BTW,
There is HandleFault InterceptStrategy, which could be used to turn a
fault message into a exception.
Here is the DSL for configure it
public void configure() throws Exception {
HandleFault handleFault =new HaneleFault();
getContext().addInterceptStrategy(handleFault);
...
}
Willem
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
> }
>
>
> On Sat, Mar 6, 2010 at 4:51 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
>> Hi,
>>
>> I have a route that looks like this:
>> from( sourceEndpoint )
>> .onException( java.lang.Throwable.class ).process(
>> new Processor() {
>> public void process(Exchange exchange) throws
>> Exception
>> {
>> log.warn( "onException\n\n\n\n" );
>> Throwable caused =
>> exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Throwable.class);
>> log.info( "caused = " +
>> caused.getClass().getCanonicalName() );
>> log.info( "caused = " +
>> caused.getMessage() );
>> log.info( "caused = " + caused.toString()
>> );
>> log.info( "caused = " + caused );
>> }
>> }).end()
>> .to( destinationEndpoint );
>>
>> Both sourceEndpoint and destinationEndpoint are CXF endpoints.
>> When destinationEndpoint is unavailable (the server is down) the onException
>> handler is thrown correctly.
>>
>> But if destinationEndpoint returns a SOAP:Fault onException isn't triggered
>> and I can't find out how to modify the SOAP:Fault that the clients of
>> sourceEndpoint receive.
>> I need to ensure that SOAP:Server faults are modified before being returned
>> to the client.
>>
>> I tried adding a processor, but that only gets called on the way In, whether
>> it returns a fault or not.
>>
>> I'm new to camel but I've managed to get most of my requirements met,
>> leaving me with just this problem that's got me completely stumped.
>>
>> Thanks
>>
>> Jim
>>
>>
>
>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Mar 7, 2010 at 8:05 AM, Claus Ibsen <cl...@gmail.com> 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
> }
>
Ah the IN OUT is playing tricks on me, you most likely have to do
public void process(Exchange exchange) {
boolean isFault = exchange.getIn().isFault();
// do something before the message is returned to the caller
>
> On Sat, Mar 6, 2010 at 4:51 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
>> Hi,
>>
>> I have a route that looks like this:
>> from( sourceEndpoint )
>> .onException( java.lang.Throwable.class ).process(
>> new Processor() {
>> public void process(Exchange exchange) throws
>> Exception
>> {
>> log.warn( "onException\n\n\n\n" );
>> Throwable caused =
>> exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Throwable.class);
>> log.info( "caused = " +
>> caused.getClass().getCanonicalName() );
>> log.info( "caused = " +
>> caused.getMessage() );
>> log.info( "caused = " + caused.toString()
>> );
>> log.info( "caused = " + caused );
>> }
>> }).end()
>> .to( destinationEndpoint );
>>
>> Both sourceEndpoint and destinationEndpoint are CXF endpoints.
>> When destinationEndpoint is unavailable (the server is down) the onException
>> handler is thrown correctly.
>>
>> But if destinationEndpoint returns a SOAP:Fault onException isn't triggered
>> and I can't find out how to modify the SOAP:Fault that the clients of
>> sourceEndpoint receive.
>> I need to ensure that SOAP:Server faults are modified before being returned
>> to the client.
>>
>> I tried adding a processor, but that only gets called on the way In, whether
>> it returns a fault or not.
>>
>> I'm new to camel but I've managed to get most of my requirements met,
>> leaving me with just this problem that's got me completely stumped.
>>
>> Thanks
>>
>> 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
>
--
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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Mar 19, 2010 at 8:04 AM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
> Thanks Claus, but that still doesn't let me do what I want and is
> inefficient.
>
We love contributions. See feel free to go ahead and create a patch
and attach it to a JIRA.
And we love more when the patch have unit tests :)
http://camel.apache.org/contributing.html
> What it won't let me do:
> I want to be able to correlate the "out" trace with the "in" trace, in one
> database row without commiting the row until the route has completed.
> This requires a JPA transaction to exist around each of the nodes that are
> called.
> I'm finding that the transaction has ended by the time of the "out" trace.
>
> Inefficiencies:
> 1. It causes the construction of the new Exchange object and a bunch of
> String objects that I don't want.
> 2. It causes the invocation of a new route, that is unnecessary.
>
> I think it would be better to:
> 1. Pass the class to use as the TraceInterceptor into Tracer.
> 2. Break the existing TraceInterceptor into two, a base class that tracks
> the RouteNodes and a subclass that implements traceExchange.
> 3. Change traceExchange so that it returns an Object and pass that Object in
> to the call to traceExchange for "out" traces.
>
> If you think this is a sane approach I can produce a patch for it.
>
> Jim
>
>
> I want to be able to correlate the
>
> On 17/03/2010 19:42, Claus Ibsen wrote:
>>
>> Hi
>>
>> Looks like the getTracedExchange method was removed a bit later. I
>> have adde a ticket to track this
>> https://issues.apache.org/activemq/browse/CAMEL-2556
>>
>>
>>
>> On Wed, Mar 17, 2010 at 7:06 PM, Jim Talbut<jt...@spudsoft.co.uk>
>> wrote:
>>
>>>
>>> I'm sorry, but I'm afraid I must be missing something.
>>> You say "just use your own JPA code to persist the message" like it's a
>>> simple thing to do, but it doesn't appear to be.
>>>
>>> The out of the box TraceInterceptor hard codes the canonical name of the
>>> class that it's loading, and loads it excplicitly, so I can't intercept
>>> that
>>> other than by providing another class in the same package.
>>> That's nasty and hacky and still doesn't solve the problem because it
>>> just
>>> gets called by the IntrospectionSupport, so I don't get the opportunity
>>> to
>>> access the Exchange object.
>>> That led me to try to replace the TraceInterceptor with my own, but that
>>> is
>>> complicated because the TraceInterceptor also builds up the
>>> TracedRouteNodes
>>> (and because I can't remove the out of the box TraceInterceptor).
>>>
>>> It seems to me that there should be a way to subclass the
>>> TraceInterceptor
>>> and just get access to the pre and post Exchange object to log it - that
>>> would need to be set on the default Trace object before any routes get
>>> created.
>>> But as I said, I must be missing something.
>>>
>>> Jim
>>>
>>>
>>>
>>> On 13/03/2010 09:06, Claus Ibsen wrote:
>>>
>>>>
>>>> You can just use your own JPA code to persist the message instead of
>>>> the out of the box feature.
>>>>
>>>>
>>>>
>>>> On Sat, Mar 13, 2010 at 9:54 AM, Jim Talbut<jt...@spudsoft.co.uk>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> On 13/03/2010 07:36, Claus Ibsen wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jt...@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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> TraceFormatter is just for logged tracing - I'm using JPA.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> 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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
Thanks Claus, but that still doesn't let me do what I want and is
inefficient.
What it won't let me do:
I want to be able to correlate the "out" trace with the "in" trace, in
one database row without commiting the row until the route has completed.
This requires a JPA transaction to exist around each of the nodes that
are called.
I'm finding that the transaction has ended by the time of the "out" trace.
Inefficiencies:
1. It causes the construction of the new Exchange object and a bunch of
String objects that I don't want.
2. It causes the invocation of a new route, that is unnecessary.
I think it would be better to:
1. Pass the class to use as the TraceInterceptor into Tracer.
2. Break the existing TraceInterceptor into two, a base class that
tracks the RouteNodes and a subclass that implements traceExchange.
3. Change traceExchange so that it returns an Object and pass that
Object in to the call to traceExchange for "out" traces.
If you think this is a sane approach I can produce a patch for it.
Jim
I want to be able to correlate the
On 17/03/2010 19:42, Claus Ibsen wrote:
> Hi
>
> Looks like the getTracedExchange method was removed a bit later. I
> have adde a ticket to track this
> https://issues.apache.org/activemq/browse/CAMEL-2556
>
>
>
> On Wed, Mar 17, 2010 at 7:06 PM, Jim Talbut<jt...@spudsoft.co.uk> wrote:
>
>> I'm sorry, but I'm afraid I must be missing something.
>> You say "just use your own JPA code to persist the message" like it's a
>> simple thing to do, but it doesn't appear to be.
>>
>> The out of the box TraceInterceptor hard codes the canonical name of the
>> class that it's loading, and loads it excplicitly, so I can't intercept that
>> other than by providing another class in the same package.
>> That's nasty and hacky and still doesn't solve the problem because it just
>> gets called by the IntrospectionSupport, so I don't get the opportunity to
>> access the Exchange object.
>> That led me to try to replace the TraceInterceptor with my own, but that is
>> complicated because the TraceInterceptor also builds up the TracedRouteNodes
>> (and because I can't remove the out of the box TraceInterceptor).
>>
>> It seems to me that there should be a way to subclass the TraceInterceptor
>> and just get access to the pre and post Exchange object to log it - that
>> would need to be set on the default Trace object before any routes get
>> created.
>> But as I said, I must be missing something.
>>
>> Jim
>>
>>
>>
>> On 13/03/2010 09:06, Claus Ibsen wrote:
>>
>>> You can just use your own JPA code to persist the message instead of
>>> the out of the box feature.
>>>
>>>
>>>
>>> On Sat, Mar 13, 2010 at 9:54 AM, Jim Talbut<jt...@spudsoft.co.uk>
>>> wrote:
>>>
>>>
>>>> On 13/03/2010 07:36, Claus Ibsen wrote:
>>>>
>>>>
>>>>> On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jt...@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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> TraceFormatter is just for logged tracing - I'm using JPA.
>>>>
>>>> Thanks.
>>>>
>>>> Jim
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Looks like the getTracedExchange method was removed a bit later. I
have adde a ticket to track this
https://issues.apache.org/activemq/browse/CAMEL-2556
On Wed, Mar 17, 2010 at 7:06 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
> I'm sorry, but I'm afraid I must be missing something.
> You say "just use your own JPA code to persist the message" like it's a
> simple thing to do, but it doesn't appear to be.
>
> The out of the box TraceInterceptor hard codes the canonical name of the
> class that it's loading, and loads it excplicitly, so I can't intercept that
> other than by providing another class in the same package.
> That's nasty and hacky and still doesn't solve the problem because it just
> gets called by the IntrospectionSupport, so I don't get the opportunity to
> access the Exchange object.
> That led me to try to replace the TraceInterceptor with my own, but that is
> complicated because the TraceInterceptor also builds up the TracedRouteNodes
> (and because I can't remove the out of the box TraceInterceptor).
>
> It seems to me that there should be a way to subclass the TraceInterceptor
> and just get access to the pre and post Exchange object to log it - that
> would need to be set on the default Trace object before any routes get
> created.
> But as I said, I must be missing something.
>
> Jim
>
>
>
> On 13/03/2010 09:06, Claus Ibsen wrote:
>>
>> You can just use your own JPA code to persist the message instead of
>> the out of the box feature.
>>
>>
>>
>> On Sat, Mar 13, 2010 at 9:54 AM, Jim Talbut<jt...@spudsoft.co.uk>
>> wrote:
>>
>>>
>>> On 13/03/2010 07:36, Claus Ibsen wrote:
>>>
>>>>
>>>> On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jt...@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.
>>>>
>>>>
>>>>
>>>
>>> TraceFormatter is just for logged tracing - I'm using JPA.
>>>
>>> Thanks.
>>>
>>> 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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
I'm sorry, but I'm afraid I must be missing something.
You say "just use your own JPA code to persist the message" like it's a
simple thing to do, but it doesn't appear to be.
The out of the box TraceInterceptor hard codes the canonical name of the
class that it's loading, and loads it excplicitly, so I can't intercept
that other than by providing another class in the same package.
That's nasty and hacky and still doesn't solve the problem because it
just gets called by the IntrospectionSupport, so I don't get the
opportunity to access the Exchange object.
That led me to try to replace the TraceInterceptor with my own, but that
is complicated because the TraceInterceptor also builds up the
TracedRouteNodes (and because I can't remove the out of the box
TraceInterceptor).
It seems to me that there should be a way to subclass the
TraceInterceptor and just get access to the pre and post Exchange object
to log it - that would need to be set on the default Trace object before
any routes get created.
But as I said, I must be missing something.
Jim
On 13/03/2010 09:06, Claus Ibsen wrote:
> You can just use your own JPA code to persist the message instead of
> the out of the box feature.
>
>
>
> On Sat, Mar 13, 2010 at 9:54 AM, Jim Talbut<jt...@spudsoft.co.uk> wrote:
>
>> On 13/03/2010 07:36, Claus Ibsen wrote:
>>
>>> On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jt...@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.
>>>
>>>
>>>
>> TraceFormatter is just for logged tracing - I'm using JPA.
>>
>> Thanks.
>>
>> Jim
>>
>>
>>
>
>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
You can just use your own JPA code to persist the message instead of
the out of the box feature.
On Sat, Mar 13, 2010 at 9:54 AM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
> On 13/03/2010 07:36, Claus Ibsen wrote:
>>
>> On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jt...@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.
>>
>>
>
> TraceFormatter is just for logged tracing - I'm using JPA.
>
> Thanks.
>
> 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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
On 13/03/2010 07:36, Claus Ibsen wrote:
> On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut<jt...@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.
>
>
TraceFormatter is just for logged tracing - I'm using JPA.
Thanks.
Jim
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Mar 13, 2010 at 8:27 AM, Jim Talbut <jt...@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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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?
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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Willem Jiang <wi...@gmail.com>.
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
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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
>>>>
>>>
>>
>>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Willem Jiang <wi...@gmail.com>.
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
>>>
>>
>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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
>>
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Willem Jiang <wi...@gmail.com>.
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
>
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
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.
My debug logs looks like this (reformatted by hand):
exchange.isFailed() = false
exchange.getIn().isFault() = false
exchange.getOut().isFault() = false
exchange.getIn() =
sun.net.www.protocol.http.HttpURLConnection$HttpInputStream@34c95
exchange.getOut() = Message: [Body is null]
exchange.getIn().header[ content-type ] = text/xml; charset=utf-8
exchange.getIn().header[ connection ] = keep-alive
exchange.getIn().header[ host ] = 192.168.1.198:9000
exchange.getIn().header[ accept ] = */*
exchange.getIn().header[ user-agent ] = Apache CXF 2.2.6
exchange.getIn().header[ date ] = Sun, 07 Mar 2010 20:02:50 GMT
exchange.getIn().header[ pragma ] = no-cache
exchange.getIn().header[ cache-control ] = private
exchange.getIn().header[ x-powered-by ] = ASP.NET
exchange.getIn().header[ soapaction ] = "http://spudsoft.co.uk/HashFiles"
exchange.getIn().header[ x-aspnet-version ] = 2.0.50727
exchange.getIn().header[ content-length ] = 394
exchange.getIn().header[ server ] = Microsoft-IIS/6.0
exchange.getIn().header[ responsecontext ] = {
org.apache.cxf.client=true,
org.apache.cxf.message.Message.PROTOCOL_HEADERS={
content-type=[text/xml; charset=utf-8],
X-AspNet-Version=[2.0.50727],
Date=[Sun, 07 Mar 2010 20:02:50 GMT],
Content-Length=[394],
X-Powered-By=[ASP.NET],
Server=[Microsoft-IIS/6.0],
Cache-Control=[private]
},
org.apache.cxf.message.inbound=true,
Content-Type=text/xml;
charset=utf-8,
org.apache.cxf.message.Message.RESPONSE_CODE=500,
org.apache.cxf.message.Message.ENCODING=UTF-8
}
It's setting the RESPONSE_CODE to 500, but not raising an exception or
setting isFault.
Is that a bug?
Jim
Re: Modifying SOAP:Fault errors raised by endpoints
Posted by Claus Ibsen <cl...@gmail.com>.
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
}
On Sat, Mar 6, 2010 at 4:51 PM, Jim Talbut <jt...@spudsoft.co.uk> wrote:
> Hi,
>
> I have a route that looks like this:
> from( sourceEndpoint )
> .onException( java.lang.Throwable.class ).process(
> new Processor() {
> public void process(Exchange exchange) throws
> Exception
> {
> log.warn( "onException\n\n\n\n" );
> Throwable caused =
> exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Throwable.class);
> log.info( "caused = " +
> caused.getClass().getCanonicalName() );
> log.info( "caused = " +
> caused.getMessage() );
> log.info( "caused = " + caused.toString()
> );
> log.info( "caused = " + caused );
> }
> }).end()
> .to( destinationEndpoint );
>
> Both sourceEndpoint and destinationEndpoint are CXF endpoints.
> When destinationEndpoint is unavailable (the server is down) the onException
> handler is thrown correctly.
>
> But if destinationEndpoint returns a SOAP:Fault onException isn't triggered
> and I can't find out how to modify the SOAP:Fault that the clients of
> sourceEndpoint receive.
> I need to ensure that SOAP:Server faults are modified before being returned
> to the client.
>
> I tried adding a processor, but that only gets called on the way In, whether
> it returns a fault or not.
>
> I'm new to camel but I've managed to get most of my requirements met,
> leaving me with just this problem that's got me completely stumped.
>
> Thanks
>
> 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