You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "alberto.zigoni" <al...@gmail.com> on 2011/07/15 13:41:26 UTC
onException vs. doTry...doCatch
I am trying to properly configure error handler with onException on this route:
<route id="cashReservationsRoute" handleFault="true">
<from uri="direct:startCashReservationsRoute" />
<onException>
<exception>org.apache.cxf.interceptor.Fault</exception>
<continued><constant>true</constant></continued>
<log message="getCashReservations() error ignored" />
<!-- <process ref="errorHandlerProcessor" /> -->
</onException>
<!-- Prepare GetReservationsCashReportReq -->
<process ref="prepareCashReservationsRequestProcessor" />
<!-- Add server token to request -->
<enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
<to uri="cxf:bean:dgwEndpoint" />
<log message="Retrieved cash reservations" />
</route>
This route is invoked by an enrich EIP in the following route:
<route id="terminalsConfiguration">
<from uri="direct:startTerminalsConfiguration" />
...
...
<split>
<simple>${body}</simple>
<log message="Processing terminal with IP address: ${body.ipAddress}" />
<!-- 2. enrich the collection by adding MachineCredential instances -->
<enrich uri="direct:startMachinesCredentialsRoute" strategyRef="setMachinesCredentialStrategy" />
<log message="Retrieved credentials for terminal: ${body.ipAddress}" />
<!-- HERE THE cashReservationsRoute IS CALLED-->
<enrich uri="direct:startCashReservationsRoute" strategyRef="setCashReservationsStrategy" />
<!-- 4.2. Add terminal profile into cache -->
<process ref="setCacheHeadersProcessor" />
<to uri="cache://credentialsCache" />
<log message="Updated credentials cache. Key: ${header.CACHE_KEY} - Value: ${body}" />
</split>
<process ref="logoutServerProcessor" />
<to uri="direct:logoutUser" />
</route>
What I want to achieve is to ignore any errors raised by the cxf endpoint in the first route and to continue processing the <split> route.
What happens is that the DefaultErrorHandler kicks in and simply skips all the processors following the failing enrich, going straight to the next split body.
Here is the log:
[ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
[ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
[ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
[ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
[ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
[ default-workqueue-5] DefaultErrorHandler ERROR Failed delivery for exchangeId: ID-localhost-55736-1310724793588-0-26. Exhausted after delivery attempt: 1 caught: org.apache.cxf.binding.soap.SoapFault: Testing only
org.apache.cxf.binding.soap.SoapFault: Testing only
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)[cxf-rt-core-2.3.2.jar:2.3.2]
at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)[cxf-rt-core-2.3.2.jar:2.3.2]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2335)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:2198)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:253)[cxf-rt-core-2.3.2.jar:2.3.2]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_26]
at java.lang.Thread.run(Thread.java:680)[:1.6.0_26]
[ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
If I configure the route like this:
<route id="cashReservationsRoute" handleFault="true">
<from uri="direct:startCashReservationsRoute" />
<!-- Prepare GetReservationsCashReportReq -->
<process ref="prepareCashReservationsRequestProcessor" />
<!-- Add server token to request -->
<enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
<doTry>
<to uri="cxf:bean:dgwEndpoint" />
<log message="Retrieved cash reservations" />
<doCatch>
<exception>org.apache.cxf.interceptor.Fault</exception>
<log message="getCashReservations() error ignored" />
<process ref="errorHandlerProcessor" /> <!-- this does nothing special, simply substitutes the out Fault with an empty bean. It is not defined in the <onException> otherwise the route would stop processing there -->
</doCatch>
</doTry>
</route>
everything works wonderfully, simply because the DefaultErrorHandler is not used.
This is the log:
[ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
[ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
[ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
[ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
[ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
Testing only
[ default-workqueue-5] terminalsConfiguration INFO Updated credentials cache. Key: 3619_0003 - Value: com.ncr.a2e.ing.routes.security.Terminal@1d764a75
[ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
I have tried using all the different error handlers, no luck.
I have tried to change from "continued" to "handled", no luck.
I would like to use onException, because it seems the preferred method to handle exceptions, but I simply cannot do it.
I think that the fact that doTry...doCatch supersedes the error handling mechanism should be pointed out in the Camel in Action book.
Alberto
--
View this message in context: http://camel.465427.n5.nabble.com/onException-vs-doTry-doCatch-tp4590348p4590348.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: onException vs. doTry...doCatch
Posted by "alberto.zigoni" <al...@gmail.com>.
Claus,
thanks for the info.
I have tried using the AggregationStrategy to handle errors, as suggested in the book, but with the onException configuration the route exits before calling the aggregate().
I will stick to the doTry...doCatch syntax for the moment.
Thanks
Alberto
Il giorno 16/lug/2011, alle ore 13.45, Claus Ibsen-2 [via Camel] ha scritto:
> On Fri, Jul 15, 2011 at 1:41 PM, alberto.zigoni
> <[hidden email]> wrote:
>
> > I am trying to properly configure error handler with onException on this route:
> >
> > <route id="cashReservationsRoute" handleFault="true">
> > <from uri="direct:startCashReservationsRoute" />
> >
> > <onException>
> > <exception>org.apache.cxf.interceptor.Fault</exception>
> > <continued><constant>true</constant></continued>
> > <log message="getCashReservations() error ignored" />
> > <!-- <process ref="errorHandlerProcessor" /> -->
> > </onException>
> >
> > <!-- Prepare GetReservationsCashReportReq -->
> > <process ref="prepareCashReservationsRequestProcessor" />
> > <!-- Add server token to request -->
> > <enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
> > <to uri="cxf:bean:dgwEndpoint" />
> > <log message="Retrieved cash reservations" />
> > </route>
> >
> > This route is invoked by an enrich EIP in the following route:
> >
> > <route id="terminalsConfiguration">
> > <from uri="direct:startTerminalsConfiguration" />
> > ...
> > ...
> > <split>
> > <simple>${body}</simple>
> > <log message="Processing terminal with IP address: ${body.ipAddress}" />
> > <!-- 2. enrich the collection by adding MachineCredential instances -->
> > <enrich uri="direct:startMachinesCredentialsRoute" strategyRef="setMachinesCredentialStrategy" />
> > <log message="Retrieved credentials for terminal: ${body.ipAddress}" />
> >
> > <!-- HERE THE cashReservationsRoute IS CALLED-->
> > <enrich uri="direct:startCashReservationsRoute" strategyRef="setCashReservationsStrategy" />
> >
> > <!-- 4.2. Add terminal profile into cache -->
> > <process ref="setCacheHeadersProcessor" />
> > <to uri="cache://credentialsCache" />
> > <log message="Updated credentials cache. Key: ${header.CACHE_KEY} - Value: ${body}" />
> > </split>
> > <process ref="logoutServerProcessor" />
> > <to uri="direct:logoutUser" />
> > </route>
> >
> > What I want to achieve is to ignore any errors raised by the cxf endpoint in the first route and to continue processing the <split> route.
> >
> > What happens is that the DefaultErrorHandler kicks in and simply skips all the processors following the failing enrich, going straight to the next split body.
> >
>
> When using Enrich you can/should handle exceptions in the aggregation strategy.
> See section 8.3.5 in the book.
>
>
> > Here is the log:
> >
> > [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
> > [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
> > [ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
> > [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
> > [ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
> > [ default-workqueue-5] DefaultErrorHandler ERROR Failed delivery for exchangeId: ID-localhost-55736-1310724793588-0-26. Exhausted after delivery attempt: 1 caught: org.apache.cxf.binding.soap.SoapFault: Testing only
> > org.apache.cxf.binding.soap.SoapFault: Testing only
> > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> > at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
> > at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)[cxf-rt-core-2.3.2.jar:2.3.2]
> > at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> > at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
> > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)[cxf-rt-core-2.3.2.jar:2.3.2]
> > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2335)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
> > at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:2198)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
> > at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:253)[cxf-rt-core-2.3.2.jar:2.3.2]
> > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_26]
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_26]
> > at java.lang.Thread.run(Thread.java:680)[:1.6.0_26]
> > [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
> >
> >
> > If I configure the route like this:
> >
> > <route id="cashReservationsRoute" handleFault="true">
> > <from uri="direct:startCashReservationsRoute" />
> >
> > <!-- Prepare GetReservationsCashReportReq -->
> > <process ref="prepareCashReservationsRequestProcessor" />
> > <!-- Add server token to request -->
> > <enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
> > <doTry>
> > <to uri="cxf:bean:dgwEndpoint" />
> > <log message="Retrieved cash reservations" />
> > <doCatch>
> > <exception>org.apache.cxf.interceptor.Fault</exception>
> > <log message="getCashReservations() error ignored" />
> > <process ref="errorHandlerProcessor" /> <!-- this does nothing special, simply substitutes the out Fault with an empty bean. It is not defined in the <onException> otherwise the route would stop processing there -->
> > </doCatch>
> > </doTry>
> > </route>
> >
> > everything works wonderfully, simply because the DefaultErrorHandler is not used.
> >
> > This is the log:
> >
> > [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
> > [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
> > [ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
> > [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
> > [ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
> > Testing only
> > [ default-workqueue-5] terminalsConfiguration INFO Updated credentials cache. Key: 3619_0003 - Value: com.ncr.a2e.ing.routes.security.Terminal@1d764a75
> > [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
> >
> > I have tried using all the different error handlers, no luck.
> > I have tried to change from "continued" to "handled", no luck.
> >
> > I would like to use onException, because it seems the preferred method to handle exceptions, but I simply cannot do it.
> >
> > I think that the fact that doTry...doCatch supersedes the error handling mechanism should be pointed out in the Camel in Action book.
> >
> > Alberto
> >
> > --
> > View this message in context: http://camel.465427.n5.nabble.com/onException-vs-doTry-doCatch-tp4590348p4590348.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://camel.465427.n5.nabble.com/onException-vs-doTry-doCatch-tp4590348p4593684.html
> To start a new topic under Camel - Users, email ml-node+465428-1832908794-4818@n5.nabble.com
> To unsubscribe from Camel - Users, click here.
--
View this message in context: http://camel.465427.n5.nabble.com/onException-vs-doTry-doCatch-tp4590348p4598454.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: onException vs. doTry...doCatch
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jul 15, 2011 at 1:41 PM, alberto.zigoni
<al...@gmail.com> wrote:
> I am trying to properly configure error handler with onException on this route:
>
> <route id="cashReservationsRoute" handleFault="true">
> <from uri="direct:startCashReservationsRoute" />
>
> <onException>
> <exception>org.apache.cxf.interceptor.Fault</exception>
> <continued><constant>true</constant></continued>
> <log message="getCashReservations() error ignored" />
> <!-- <process ref="errorHandlerProcessor" /> -->
> </onException>
>
> <!-- Prepare GetReservationsCashReportReq -->
> <process ref="prepareCashReservationsRequestProcessor" />
> <!-- Add server token to request -->
> <enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
> <to uri="cxf:bean:dgwEndpoint" />
> <log message="Retrieved cash reservations" />
> </route>
>
> This route is invoked by an enrich EIP in the following route:
>
> <route id="terminalsConfiguration">
> <from uri="direct:startTerminalsConfiguration" />
> ...
> ...
> <split>
> <simple>${body}</simple>
> <log message="Processing terminal with IP address: ${body.ipAddress}" />
> <!-- 2. enrich the collection by adding MachineCredential instances -->
> <enrich uri="direct:startMachinesCredentialsRoute" strategyRef="setMachinesCredentialStrategy" />
> <log message="Retrieved credentials for terminal: ${body.ipAddress}" />
>
> <!-- HERE THE cashReservationsRoute IS CALLED-->
> <enrich uri="direct:startCashReservationsRoute" strategyRef="setCashReservationsStrategy" />
>
> <!-- 4.2. Add terminal profile into cache -->
> <process ref="setCacheHeadersProcessor" />
> <to uri="cache://credentialsCache" />
> <log message="Updated credentials cache. Key: ${header.CACHE_KEY} - Value: ${body}" />
> </split>
> <process ref="logoutServerProcessor" />
> <to uri="direct:logoutUser" />
> </route>
>
> What I want to achieve is to ignore any errors raised by the cxf endpoint in the first route and to continue processing the <split> route.
>
> What happens is that the DefaultErrorHandler kicks in and simply skips all the processors following the failing enrich, going straight to the next split body.
>
When using Enrich you can/should handle exceptions in the aggregation strategy.
See section 8.3.5 in the book.
> Here is the log:
>
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
> [ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
> [ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
> [ default-workqueue-5] DefaultErrorHandler ERROR Failed delivery for exchangeId: ID-localhost-55736-1310724793588-0-26. Exhausted after delivery attempt: 1 caught: org.apache.cxf.binding.soap.SoapFault: Testing only
> org.apache.cxf.binding.soap.SoapFault: Testing only
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)[cxf-rt-core-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)[cxf-rt-core-2.3.2.jar:2.3.2]
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2335)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:2198)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:253)[cxf-rt-core-2.3.2.jar:2.3.2]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_26]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_26]
> at java.lang.Thread.run(Thread.java:680)[:1.6.0_26]
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
>
>
> If I configure the route like this:
>
> <route id="cashReservationsRoute" handleFault="true">
> <from uri="direct:startCashReservationsRoute" />
>
> <!-- Prepare GetReservationsCashReportReq -->
> <process ref="prepareCashReservationsRequestProcessor" />
> <!-- Add server token to request -->
> <enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
> <doTry>
> <to uri="cxf:bean:dgwEndpoint" />
> <log message="Retrieved cash reservations" />
> <doCatch>
> <exception>org.apache.cxf.interceptor.Fault</exception>
> <log message="getCashReservations() error ignored" />
> <process ref="errorHandlerProcessor" /> <!-- this does nothing special, simply substitutes the out Fault with an empty bean. It is not defined in the <onException> otherwise the route would stop processing there -->
> </doCatch>
> </doTry>
> </route>
>
> everything works wonderfully, simply because the DefaultErrorHandler is not used.
>
> This is the log:
>
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
> [ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
> [ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
> Testing only
> [ default-workqueue-5] terminalsConfiguration INFO Updated credentials cache. Key: 3619_0003 - Value: com.ncr.a2e.ing.routes.security.Terminal@1d764a75
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
>
> I have tried using all the different error handlers, no luck.
> I have tried to change from "continued" to "handled", no luck.
>
> I would like to use onException, because it seems the preferred method to handle exceptions, but I simply cannot do it.
>
> I think that the fact that doTry...doCatch supersedes the error handling mechanism should be pointed out in the Camel in Action book.
>
> Alberto
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/onException-vs-doTry-doCatch-tp4590348p4590348.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: onException vs. doTry...doCatch
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jul 15, 2011 at 1:41 PM, alberto.zigoni
<al...@gmail.com> wrote:
> I am trying to properly configure error handler with onException on this route:
>
> <route id="cashReservationsRoute" handleFault="true">
> <from uri="direct:startCashReservationsRoute" />
>
> <onException>
> <exception>org.apache.cxf.interceptor.Fault</exception>
> <continued><constant>true</constant></continued>
> <log message="getCashReservations() error ignored" />
> <!-- <process ref="errorHandlerProcessor" /> -->
> </onException>
>
> <!-- Prepare GetReservationsCashReportReq -->
> <process ref="prepareCashReservationsRequestProcessor" />
> <!-- Add server token to request -->
> <enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
> <to uri="cxf:bean:dgwEndpoint" />
> <log message="Retrieved cash reservations" />
> </route>
>
> This route is invoked by an enrich EIP in the following route:
>
> <route id="terminalsConfiguration">
> <from uri="direct:startTerminalsConfiguration" />
> ...
> ...
> <split>
> <simple>${body}</simple>
> <log message="Processing terminal with IP address: ${body.ipAddress}" />
> <!-- 2. enrich the collection by adding MachineCredential instances -->
> <enrich uri="direct:startMachinesCredentialsRoute" strategyRef="setMachinesCredentialStrategy" />
> <log message="Retrieved credentials for terminal: ${body.ipAddress}" />
>
> <!-- HERE THE cashReservationsRoute IS CALLED-->
> <enrich uri="direct:startCashReservationsRoute" strategyRef="setCashReservationsStrategy" />
>
> <!-- 4.2. Add terminal profile into cache -->
> <process ref="setCacheHeadersProcessor" />
> <to uri="cache://credentialsCache" />
> <log message="Updated credentials cache. Key: ${header.CACHE_KEY} - Value: ${body}" />
> </split>
> <process ref="logoutServerProcessor" />
> <to uri="direct:logoutUser" />
> </route>
>
> What I want to achieve is to ignore any errors raised by the cxf endpoint in the first route and to continue processing the <split> route.
>
> What happens is that the DefaultErrorHandler kicks in and simply skips all the processors following the failing enrich, going straight to the next split body.
>
> Here is the log:
>
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
> [ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724816172
> [ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
> [ default-workqueue-5] DefaultErrorHandler ERROR Failed delivery for exchangeId: ID-localhost-55736-1310724793588-0-26. Exhausted after delivery attempt: 1 caught: org.apache.cxf.binding.soap.SoapFault: Testing only
> org.apache.cxf.binding.soap.SoapFault: Testing only
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:99)[cxf-rt-core-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)[cxf-rt-bindings-soap-2.3.2.jar:2.3.2]
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[cxf-api-2.3.2.jar:2.3.2]
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)[cxf-rt-core-2.3.2.jar:2.3.2]
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2335)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:2198)[cxf-rt-transports-http-2.3.2.jar:2.3.2]
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:253)[cxf-rt-core-2.3.2.jar:2.3.2]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_26]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_26]
> at java.lang.Thread.run(Thread.java:680)[:1.6.0_26]
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
>
>
> If I configure the route like this:
>
> <route id="cashReservationsRoute" handleFault="true">
> <from uri="direct:startCashReservationsRoute" />
>
> <!-- Prepare GetReservationsCashReportReq -->
> <process ref="prepareCashReservationsRequestProcessor" />
> <!-- Add server token to request -->
> <enrich uri="direct:getServerToken" strategyRef="setTokenToGenericRequestStrategy" />
> <doTry>
> <to uri="cxf:bean:dgwEndpoint" />
> <log message="Retrieved cash reservations" />
> <doCatch>
> <exception>org.apache.cxf.interceptor.Fault</exception>
> <log message="getCashReservations() error ignored" />
> <process ref="errorHandlerProcessor" /> <!-- this does nothing special, simply substitutes the out Fault with an empty bean. It is not defined in the <onException> otherwise the route would stop processing there -->
> </doCatch>
> </doTry>
> </route>
>
> everything works wonderfully, simply because the DefaultErrorHandler is not used.
>
> This is the log:
>
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
> [ default-workqueue-5] terminalsConfiguration INFO Retrieved credentials for terminal: 192.168.1.3
> [ default-workqueue-5] route2 INFO Server token retrieved from token cache. Value: 1310724676861
> [ default-workqueue-5] cashReservationsRoute INFO getCashReservations() error ignored
> Testing only
> [ default-workqueue-5] terminalsConfiguration INFO Updated credentials cache. Key: 3619_0003 - Value: com.ncr.a2e.ing.routes.security.Terminal@1d764a75
> [ default-workqueue-5] terminalsConfiguration INFO Processing terminal with IP address: 192.168.1.4
>
> I have tried using all the different error handlers, no luck.
> I have tried to change from "continued" to "handled", no luck.
>
> I would like to use onException, because it seems the preferred method to handle exceptions, but I simply cannot do it.
>
> I think that the fact that doTry...doCatch supersedes the error handling mechanism should be pointed out in the Camel in Action book.
It does as it states that doTry .. doCatch works in similar ways as
try .. catch does in Java. eg if any exception is thrown it will be
caught by the catch block.
>
> Alberto
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/onException-vs-doTry-doCatch-tp4590348p4590348.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/