Hi Yeah the TX stuff does the final rollback or commit. But you have surfaced an use-case where using TX but with routes with the onException might be a valid point, so you can use both (TX + onException) but not redelivery as this is done by the TX manager. And also the onException could "reset the exception flag" so there wont be a TX rollback.
So using TX but still want to use onException for eg. taking a detour in the route path should maybe be possible. As said in previous mails in this thread there is much stuff for investigations and debate as well ;) Maybe if you have the time could rewrite your requirements and some descriptions what should happen in the various situations when an exception occur. It would help when/if we improve Camel in this area and you make sure your use-case is better supported out-of-the-box. /Claus Ibsen Apache Camel Committer Blog: http://davsclaus.blogspot.com/ On Fri, Nov 21, 2008 at 9:42 AM, Fush <[EMAIL PROTECTED]> wrote: > > Thanks again for following this up. I'll be watching the Jira issue. > > Regarding writing my own error handler, that is a tempting option. But you > also said that when using transactions, it's "all or nothing". I still want > to use transactions, to make sure messages are not removed from the queue > before they are handled correctly. So that would prevent me from using my > own Camel error handler, right? > > Claus Ibsen-2 wrote: >> >> Hi >> >> #1 + #2 >> Yeah you have a use case that is a bit more advanced. I have created a >> ticket to make it easier to attach a predicate to the onException so >> you can do your custom test here also before the onexception is >> triggered. >> http://issues.apache.org/activemq/browse/CAMEL-1104 >> >> You could however write your own customized exception policy strategy: >> http://activemq.apache.org/camel/error-handler.html >> >> Camel has a default strategy that is used to find the matching >> exception thrown in the list of onException tags. >> >> There is a sample on the link above. Basically what you have to do is >> to find the matching onException to use from the given map of >> exception types. The last parameter is the actual exception thrown. >> >> So if the last exception is your special exception you can do the enum >> test and find the correct onException from the map, and return it. >> >> I am afraid the sample is for Java DSL so you could try to see if you >> can get it to work in Spring DSL as well. Let me know how it goes. >> >> >> /Claus Ibsen >> Apache Camel Committer >> Blog: http://davsclaus.blogspot.com/ >> > > -- > View this message in context: > http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20617200.html > Sent from the Camel - Users mailing list archive at Nabble.com. > >
