Mule

Improve the <default-exception-strategy> configuration

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.0-RC2
  • Fix Version/s: 2.0.0
  • Component/s: Core: Exception Handling
  • Labels:
    None
  • User impact:
    High
  • Similar Issues:
    MULE-5899 As a user I want much improved documentation for Mule 3.1/3.2 on how to configure the default-exception-strategy element to achieve common use cases
    MULE-5731 "default-service-exception-strategy" is permitted in flows
    MULE-5738 When configuring <default-exception-strategy> inbound transaction is committed by default when no commit or rollback pattern is configured
    MULE-14 Default exception strategy on the Model
    MULE-4341 Transformerconfigured on an endpoint in exception-strategy are ignored
    MULE-4515 default-service-exception-strategy does not honor exception-type-filter
    MULE-5895 As a user I want to be able to define a custom default exception strategy that is used when a a flow or service does not define one explicitly
    MULE-4640 Unify default connector and service exception strategy or limit configuration
    MULE-3196 default-connector-exception-strategy should not be able to be configured on model should it?
    MULE-4632 Configuring default-service-exception-strategy on connector throws NullPointerException

Description

Add a couple of configuration params to the default-component-exception-strategy for

  1. rolling back the current transaction or not
  2. firing JMX exception notifications (see MULE-3127)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Perepelytsya added a comment - 17/Mar/08 11:32 AM

Long overdue

Let's bring the rollback rules a step forward and allow for a fine-grained control based on the exception type (I think there were 4 availabe, e.g. handleRoutingException, handleMessagingException, etc). Not sure if we want to go as fas as allowing per-exception class granularity, as e.g. spring transaction config allows, like -RoutingException (minus in front would mean rollback), MyCustomException ( would still mean a commit if this exception is the cause). Comments are welcome.

Show
Andrew Perepelytsya added a comment - 17/Mar/08 11:32 AM Long overdue Let's bring the rollback rules a step forward and allow for a fine-grained control based on the exception type (I think there were 4 availabe, e.g. handleRoutingException, handleMessagingException, etc). Not sure if we want to go as fas as allowing per-exception class granularity, as e.g. spring transaction config allows, like -RoutingException (minus in front would mean rollback), MyCustomException ( would still mean a commit if this exception is the cause). Comments are welcome.
Hide
Permalink
Ross Mason added a comment - 17/Mar/08 06:23 PM

how about something like -

<commit-transaction expression="java.,javax."/>
<rollback-transaction expression="com.foo.MyException,com.foo.bar.*"/>

This would be pretty easy

Show
Ross Mason added a comment - 17/Mar/08 06:23 PM how about something like - <commit-transaction expression="java.,javax."/> <rollback-transaction expression="com.foo.MyException,com.foo.bar.*"/> This would be pretty easy
Hide
Permalink
Andrew Perepelytsya added a comment - 21/Mar/08 01:57 PM

Confluence formatting interfered. There should be a minus sign after an exception class name in my example above.

The concern with your suggestion Ross, is that one would potentially need to define commit/rollback rules several times depending on the exception type which triggered it (e.g. routing vs messaging error). Your variant, however, may allow for more complex expressions. Can start with any, and improve after we get something.

Show
Andrew Perepelytsya added a comment - 21/Mar/08 01:57 PM Confluence formatting interfered. There should be a minus sign after an exception class name in my example above. The concern with your suggestion Ross, is that one would potentially need to define commit/rollback rules several times depending on the exception type which triggered it (e.g. routing vs messaging error). Your variant, however, may allow for more complex expressions. Can start with any, and improve after we get something.
Hide
Permalink
Ross Mason added a comment - 21/Mar/08 07:36 PM

I've implemented it as above which I think ill be useful for many cases. It ould be easy to enhance further if necessary. See r11468

Show
Ross Mason added a comment - 21/Mar/08 07:36 PM I've implemented it as above which I think ill be useful for many cases. It ould be easy to enhance further if necessary. See r11468
Hide
Permalink
Daniel Feist added a comment - 08/Apr/08 11:40 AM

Reopening to correct fix version

Show
Daniel Feist added a comment - 08/Apr/08 11:40 AM Reopening to correct fix version

People

Vote (0)
Watch (0)

Dates

  • Created:
    17/Mar/08 09:49 AM
    Updated:
    08/Apr/08 11:40 AM
    Resolved:
    08/Apr/08 11:40 AM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.