JIRA

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Use Agile By Default
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile Access more options (Alt+g)
  • Create Issue
  • Mule
  • 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

  • Agile Board
  • More Actions
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.3 M2
  • Component/s: Core: Exception Handling
  • Labels:
    None
  • User impact:
    Medium
  • Effort points:
    3
  • Similar Issues:
    None
  • Effort:
    S
  • % Users Impacted:
    >80%
  • Value:
    5

Description

Acceptance Criteria

  1. Must be able to redefine default exception strategy for flows and services in a single place.
  2. If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
  3. If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
    When:
    <mule>
      <configuration defaultExceptionStrategy-ref="dlqExceptionStrategy"/>
    
      <catch-exception-strategy name="dlqExceptionStrategy">
        <jms:outbound-endpoint queue="dlq">
           <jms:transaction action="ALWAYS_BEGIN"/>
        </jms:outbound-endpoint>
      </catch-exception-strategy>
    
    
      <flow name="A">
        ...
      </flow>
    
      <model>
        <service name="B">
          ...
        </service>
      </model>
    </mule>

    Then:

    • flow A uses exception strategy defined in global-exception-strategy
    • service B uses exception strategy defined in global-exception-strategy
  4. If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
    When:
    <mule>
      <configuration defaultExceptionStrategy-ref="dlqExceptionStrategy"/>
    
      <catch-exception-strategy name="dlqExceptionStrategy">
        <jms:outbound-endpoint queue="dlq">
           <jms:transaction action="ALWAYS_BEGIN"/>
        </jms:outbound-endpoint>
      </catch-exception-strategy>
    
      <flow name="A">
        ...
      </flow>
    
      <model>
        <default-exception-strategy>
          ...
        </default-exception-strategy>
    
        <service name="B">
          ...
        </service>
      </model>
    </mule>

    Then:

    • flow A uses exception strategy defined within it
    • service B uses exception strategy defined within model
  5. If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
    When:
    <mule>
      <configuration defaultExceptionStrategy-ref="dlqExceptionStrategy"/>
    
      <catch-exception-strategy name="dlqExceptionStrategy">
        <jms:outbound-endpoint queue="dlq">
           <jms:transaction action="ALWAYS_BEGIN"/>
        </jms:outbound-endpoint>
      </catch-exception-strategy>
    
      <flow name="A">
        ...
        <default-exception-strategy>
          ...
        </default-exception-strategy>
      </flow>
    
      <flow name="B">
        ...
      </flow>
    
      <model>
        <default-exception-strategy>
          ...
        </default-exception-strategy>
    
        <service name="C">
          ...
          <default-exception-strategy>
             ...
          </default-exception-strategy>
        </service>
    
        <service name="D">
          ...
        </service>
      </model>
    </mule>

    Then:

    • flow A uses exception strategy defined within it
    • flow B uses global exception strategy
    • service C uses exception strategy defined within it
    • service D uses exception strategy defined within model

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
Daniel Feist made changes - 18/Nov/11 07:24 AM
Field Original Value New Value
Description *Acceptance Criteria*
- A custom default exception strategy can be configured, it should not have a name.
- If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
- The same custom default exception strategy instance is used for all flows and services with no exception strategy explicitly configured.
Ramiro Rinaudo made changes - 27/Dec/11 07:15 AM
Fix Version/s New Backlog [ 11111 ]
Fix Version/s 3.3 M2 [ 11119 ]
Ramiro Rinaudo made changes - 27/Dec/11 11:17 AM
Value 5
Priority To be reviewed [ 6 ] Critical [ 2 ]
Effort S
% Users Impacted >80%
Assignee Pablo La Greca [ pablo.lagreca.ce ]
Ramiro Rinaudo made changes - 02/Jan/12 04:07 PM
Effort points 3
Pablo La Greca made changes - 09/Jan/12 11:35 AM
Comment [ Proposed solution:
Restore AbstractExceptionListener.
Make AbstractExceptionStrategy inherit from AbstractExceptionListener.
Deprecate AbstractExceptionStrategy since it's used as base clase for SystemExceptionHandler also.

Restore DefaultServiceExceptionStrategy.
Make DefaultMessagingExceptionStrategy inherit from DefaultServiceExceptionStrategy.
Deprecate DefaultServiceExceptionStrategy since DefaultMessagingExceptionStrategy fits better.

Keep handleException(Exception, Event, RollbackSourceCallback) in DefaultMessagingExceptionStrategy and deprecate it. It will call handleException(Exception,Event).

Change TemplateMessagingExceptionStrategy to inherit from it for future custom exception strategies for Mule 3.3.

Default behavior:
* process statistics
* log exception
* evaluate if should rollback
** if rollback then resolve transaction
** if not rollback keep transaction in context
* add exceptionPayload to MuleMessage
* route event through configured message processors
* process reply to property
* close stream
* continue processing with event as result of routing it through exception strategy
* cause exception re-throwing

Behavior customization by subclasses:
* WILL NOT ALLOW TO OVERRIDE handleException(..) since it defines behavior that every exception strategy must implement
* Change log exception behavior
* Change rollback evaluation - default is to rollback
** Rollback will cause exception to be re-thrown and transaction to be resolved right away
** No rollback will cause exception to not be re-thrown as default
* Change MuleEvent before routing it through MPs
* Change MuleEvent after routing it through MPs
* Allow/Disallow to process reply to - default is process reply to
* Allow/Disallow to close stream - default is close stream
* Allow/Disallow to re-throw exception - default depends on rollback/commit
** if re-throw exception will be re-thrown so it can be managed by parent exception strategy / transport connector
** if not re-throw exception then return processed event without exceptionPayload
]
Pablo La Greca made changes - 09/Jan/12 11:35 AM
Comment [ Spreadsheet with backward compatibility changes: https://docs.google.com/a/mulesource.com/spreadsheet/ccc?key=0AugK5pm_7Q_2dEF4SEFpMHJRSVJNUXh4VUdmTkM0VEE ]
Pablo La Greca made changes - 09/Jan/12 09:09 PM
Description *Acceptance Criteria*
- A custom default exception strategy can be configured, it should not have a name.
- If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
- The same custom default exception strategy instance is used for all flows and services with no exception strategy explicitly configured.
*Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within it
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
Ramiro Rinaudo made changes - 10/Jan/12 08:13 AM
Status Open [ 1 ] In Progress [ 3 ]
Alejandro Sequeira made changes - 10/Jan/12 01:06 PM
Description *Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within it
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
*Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within module
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
Pablo La Greca made changes - 12/Jan/12 12:33 PM
Description *Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within module
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
*Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within model
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
Hide
Permalink
Pablo La Greca added a comment - 12/Jan/12 01:00 PM

Documentation http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling+Reuse+Documentation

Show
Pablo La Greca added a comment - 12/Jan/12 01:00 PM Documentation http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling+Reuse+Documentation
Pablo La Greca
16/Jan/12 08:11 AM
View full commit
MULE-5895, MULE-5896 feature default exception strategy customization and global exception strategies git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x@23609 bf997673-6b11-0410-b953-e057580c5b09
mule-3.3.3
+15
-2
core/src/main/java/org/mule/DefaultMuleContext.java
+6
-
core/src/main/java/org/mule/api/MuleContext.java
+1
-
core/src/main/java/org/mule/api/config/MuleProperties.java
+4
-2
core/src/main/java/org/mule/construct/AbstractFlowConstruct.java
+4
-
core/src/main/java/org/mule/construct/builder/AbstractFlowConstructBuilder.java
... 20 more files not shown
Hide
Permalink
Pablo La Greca added a comment - 16/Jan/12 08:18 AM

https://fisheye.codehaus.org/changelog/mule/?cs=23609

Show
Pablo La Greca added a comment - 16/Jan/12 08:18 AM https://fisheye.codehaus.org/changelog/mule/?cs=23609
Pablo La Greca
23/Jan/12 02:52 PM
View full commit
MULE-5895, MULE-5896 - changing configuration style to use attribute as a reference to default exception strategy instead of a full exception strategy definition git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x@23701 bf997673-6b11-0410-b953-e057580c5b09
mule-3.3.3
+13
-4
core/src/main/java/org/mule/DefaultMuleContext.java
+8
-
core/src/main/java/org/mule/api/config/MuleConfiguration.java
+28
-11
core/src/main/java/org/mule/config/DefaultMuleConfiguration.java
+4
-4
core/src/main/java/org/mule/construct/AbstractFlowConstruct.java
+1
-1
core/src/main/java/org/mule/exception/AbstractExceptionListener.java
... 12 more files not shown
Hide
Permalink
Pablo La Greca added a comment - 23/Jan/12 02:53 PM

Documentation style change according to feedback:
https://fisheye.codehaus.org/changelog/mule/?cs=23701

Show
Pablo La Greca added a comment - 23/Jan/12 02:53 PM Documentation style change according to feedback: https://fisheye.codehaus.org/changelog/mule/?cs=23701
Pablo La Greca made changes - 23/Jan/12 02:55 PM
Description *Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within model
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration>
    <catch-exception-strategy>
      <jms:outbound-endpoint queue="dlq">
        <jms:transaction action="ALWAYS_BEGIN"/>
      </jms:outbound-endpoint>
    </catch-exception-strategy>
  </configuration>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
*Acceptance Criteria*
# Must be able to redefine default exception strategy for flows and services in a single place.
# If a flow or service is configured without an explicitly defined exception strategy the custom default exception strategy is used.
# If there's a global exception strategy configured and no other exception strategy configured then flows / services must use that exception strategy.
*When:*
{code}
<mule>
  <configuration defaultExceptionStrategy-ref="dlqExceptionStrategy"/>

  <catch-exception-strategy name="dlqExceptionStrategy">
    <jms:outbound-endpoint queue="dlq">
       <jms:transaction action="ALWAYS_BEGIN"/>
    </jms:outbound-endpoint>
  </catch-exception-strategy>


  <flow name="A">
    ...
  </flow>

  <model>
    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined in global-exception-strategy
** service B uses exception strategy defined in global-exception-strategy
# If there's a global exception strategy configured, an exception strategy configured for a model then services within that model must use exception strategy configured in the model.
*When:*
{code}
<mule>
  <configuration defaultExceptionStrategy-ref="dlqExceptionStrategy"/>

  <catch-exception-strategy name="dlqExceptionStrategy">
    <jms:outbound-endpoint queue="dlq">
       <jms:transaction action="ALWAYS_BEGIN"/>
    </jms:outbound-endpoint>
  </catch-exception-strategy>

  <flow name="A">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="B">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** service B uses exception strategy defined within model
# If there's a global exception strategy configured, an exception strategy configured in a model and a service with a configured exception strategy within that model, then for that service the exception strategy to use must be the one defined in the service.
*When:*
{code}
<mule>
  <configuration defaultExceptionStrategy-ref="dlqExceptionStrategy"/>

  <catch-exception-strategy name="dlqExceptionStrategy">
    <jms:outbound-endpoint queue="dlq">
       <jms:transaction action="ALWAYS_BEGIN"/>
    </jms:outbound-endpoint>
  </catch-exception-strategy>

  <flow name="A">
    ...
    <default-exception-strategy>
      ...
    </default-exception-strategy>
  </flow>

  <flow name="B">
    ...
  </flow>

  <model>
    <default-exception-strategy>
      ...
    </default-exception-strategy>

    <service name="C">
      ...
      <default-exception-strategy>
         ...
      </default-exception-strategy>
    </service>

    <service name="D">
      ...
    </service>
  </model>
</mule>
{code}
*Then:*
** flow A uses exception strategy defined within it
** flow B uses global exception strategy
** service C uses exception strategy defined within it
** service D uses exception strategy defined within model
Pablo La Greca
24/Jan/12 08:17 AM
View full commit
MULE-5895, MULE-5896 - forgot to call super.doParse(..) git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x@23705 bf997673-6b11-0410-b953-e057580c5b09
mule-3.3.3
+1
-
modules/spring-config/src/main/java/org/mule/config/spring/parsers/specific/ConfigurationDefinitionParser.java
Hide
Permalink
Pablo La Greca added a comment - 24/Jan/12 08:18 AM

Fixing introduced bug:
https://fisheye.codehaus.org/changelog/mule/?cs=23705

Show
Pablo La Greca added a comment - 24/Jan/12 08:18 AM Fixing introduced bug: https://fisheye.codehaus.org/changelog/mule/?cs=23705
Pablo La Greca
06/Feb/12 01:30 PM
View full commit
MULE-5895 - rollback exception strategy - next commit will fix DefaultInboundEndpoint git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x@23825 bf997673-6b11-0410-b953-e057580c5b09
mule-3.3.3
+2
-1
core/src/main/java/org/mule/api/endpoint/InboundEndpoint.java
Added
core/src/main/java/org/mule/api/exception/MessageRedeliveredException.java
+7
-
core/src/main/java/org/mule/api/transport/Connector.java
+1
-3
core/src/main/java/org/mule/construct/AbstractFlowConstruct.java
+40
-3
core/src/main/java/org/mule/construct/AbstractPipeline.java
... 43 more files not shown
Pablo La Greca made changes - 06/Feb/12 01:33 PM
Resolution Fixed [ 1 ]
Status In Progress [ 3 ] Closed [ 6 ]
Hide
Permalink
Pablo La Greca added a comment - 06/Feb/12 01:36 PM - edited

Detailed documentation about this feature can be found here: http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling+Reuse

Show
Pablo La Greca added a comment - 06/Feb/12 01:36 PM - edited Detailed documentation about this feature can be found here: http://www.mulesoft.org/documentation/display/MULECDEV/Error+Handling+Reuse
Pablo La Greca made changes - 06/Feb/12 01:38 PM
Status Closed [ 6 ] Reopened [ 4 ]
Resolution Fixed [ 1 ]
Pablo La Greca made changes - 06/Feb/12 01:38 PM
Resolution Fixed [ 1 ]
Status Reopened [ 4 ] Closed [ 6 ]
Daniel Feist
07/Feb/12 06:35 AM
View full commit
Merged revisions 23820-23825,23827,23829-23830 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.x ................ r23820 | mike.schilling | 2012-02-03 21:38:11 -0300 (Fri, 03 Feb 2012) | 20 lines Merged revisions 23819 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.2.x ................ r23819 | mike.schilling | 2012-02-03 16:04:59 -0800 (Fri, 03 Feb 2012) | 12 lines Merged revisions 23818 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.1.x ........ r23818 | mike.schilling | 2012-02-03 15:42:40 -0800 (Fri, 03 Feb 2012) | 3 lines MULE-5649 Propagate "Stop" the MPs is an async branch ........ NOTE: There was no bug in this codeline. This integrates only the test and test framework. ................ ................ r23821 | evangelinamrm | 2012-02-06 10:47:50 -0300 (Mon, 06 Feb 2012) | 2 lines Ignore test until fixed since it fails with keystore in bamboo ................ r23822 | svacas | 2012-02-06 11:47:37 -0300 (Mon, 06 Feb 2012) | 5 lines MULE-5914: Implement <foreach> message processor -add map iteration support -package refactoring ................ r23823 | evangelinamrm | 2012-02-06 12:23:35 -0300 (Mon, 06 Feb 2012) | 4 lines MULE-5916: Improve CXF error handling The dispatch exception is not showing the cause of the exception ................ r23824 | evangelinamrm | 2012-02-06 14:47:44 -0300 (Mon, 06 Feb 2012) | 2 lines Exclude failing SFTP tests until fixed ................ r23825 | pablo.lagreca | 2012-02-06 16:30:31 -0300 (Mon, 06 Feb 2012) | 1 line MULE-5895 - rollback exception strategy - next commit will fix DefaultInboundEndpoint ................ r23827 | dirk.olmes | 2012-02-06 21:49:18 -0300 (Mon, 06 Feb 2012) | 2 lines Mule IDE is no longer supported, remove support files from the examples ................ r23829 | dirk.olmes | 2012-02-06 23:30:14 -0300 (Mon, 06 Feb 2012) | 2 lines fix the assembly whitelist: the .muleide support files are gone ................ r23830 | dirk.olmes | 2012-02-06 23:30:57 -0300 (Mon, 06 Feb 2012) | 9 lines Merged revisions 23828 via svnmerge from https://svn.codehaus.org/mule/branches/mule-3.2.x ........ r23828 | dirk.olmes | 2012-02-07 02:46:41 +0100 (Tue, 07 Feb 2012) | 1 line MULE-6039 Configuration Reloading Fails for multiple config files ........ ................ git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x-event-copying@23833 bf997673-6b11-0410-b953-e057580c5b09
mule-3.x-event-copying
+2
-1
core/src/main/java/org/mule/api/endpoint/InboundEndpoint.java
Added
core/src/main/java/org/mule/api/exception/MessageRedeliveredException.java
+7
-
core/src/main/java/org/mule/api/transport/Connector.java
+1
-3
core/src/main/java/org/mule/construct/AbstractFlowConstruct.java
+40
-3
core/src/main/java/org/mule/construct/AbstractPipeline.java
... 68 more files not shown
Hide
Permalink
Erich F. Leipold added a comment - 23/Apr/12 12:25 PM

Will this cover system exceptions during a message flow? For example, if the HTTP server throws a "Connection refused" exception while trying to process a message, will the default exception strategy catch this, even though it is a system level exception?

Show
Erich F. Leipold added a comment - 23/Apr/12 12:25 PM Will this cover system exceptions during a message flow? For example, if the HTTP server throws a "Connection refused" exception while trying to process a message, will the default exception strategy catch this, even though it is a system level exception?
Transition Time In Source Status Execution Times Last Executer Last Execution Date
Open Open In Progress In Progress
53d 50m 1 Ramiro Rinaudo 10/Jan/12 08:13 AM
In Progress In Progress Closed Closed
27d 5h 20m 1 Pablo La Greca 06/Feb/12 01:33 PM
Closed Closed Reopened Reopened
4m 38s 1 Pablo La Greca 06/Feb/12 01:38 PM
Reopened Reopened Closed Closed
25s 1 Pablo La Greca 06/Feb/12 01:38 PM
This list may be incomplete, as errors occurred whilst retrieving source from linked applications:
  • Repository mule on http://foo.bar/ failed: Error in remote call to 'FishEye 0 (http://foo.bar/)' (http://foo.bar) [AbstractRestCommand{path='/rest-service-fe/changeset-v1/listChangesets/', params={expand=changesets[-21:-1].revisions[0:29], comment=MULE-5895, p4JobFixed=MULE-5895, rep=mule}, methodType=GET}] : java.net.UnknownHostException: foo.bar

People

  • Assignee:
    Pablo La Greca
    Reporter:
    Daniel Feist
Vote (0)
Watch (0)

Dates

  • Created:
    18/Nov/11 07:22 AM
    Updated:
    23/Apr/12 12:25 PM
    Resolved:
    06/Feb/12 01:38 PM

Agile

  • View on Board
  • Atlassian JIRA (v5.0.7#734-sha1:8ad78a6)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.