The AbstractExceptionListener handles the LifecycleException twice

Details

  • User impact:
    Medium
  • Similar Issues:
    None

Description

The AbstractExceptionListener handles the LifecycleException twice.

At first it handles it correctly as LifecycleException by calling handleLifecycleException() but after that it treats it as a MessagingException by calling handleMessagingException().

This is the original code:

public void exceptionThrown(Exception e)
{
    if (enableNotifications)
    {
        fireNotification(new ExceptionNotification(e));
    }

    logException(e);
    handleTransaction(e);

    Throwable t = getExceptionType(e, RoutingException.class);
    if (t != null)
    {
        RoutingException re = (RoutingException) t;
        handleRoutingException(re.getMuleMessage(), re.getEndpoint(), e);
        return;
    }

    t = getExceptionType(e, MessagingException.class);
    if (t != null)
    {
        MessagingException me = (MessagingException) t;
        handleMessagingException(me.getMuleMessage(), e);
        return;
    }

    t = getExceptionType(e, LifecycleException.class);
    if (t != null)
    {
        LifecycleException le = (LifecycleException) t;
        handleLifecycleException(le.getComponent(), e);
        // TODO This if/else should be removed
        if (RequestContext.getEventContext() != null)
        {
            handleMessagingException(RequestContext.getEventContext().getMessage(), e);
        }
        else
        {
            logger.info("There is no current event available, routing Null message with the exception");
            handleMessagingException(new DefaultMuleMessage(NullPayload.getInstance()), e);
        }
        return;
    }

    handleStandardException(e);
}

It should be:

public void exceptionThrown(Exception e)
{
    if (enableNotifications)
    {
        fireNotification(new ExceptionNotification(e));
    }

    logException(e);
    handleTransaction(e);

    Throwable t = getExceptionType(e, RoutingException.class);
    if (t != null)
    {
        RoutingException re = (RoutingException) t;
        handleRoutingException(re.getMuleMessage(), re.getEndpoint(), e);
        return;
    }

    t = getExceptionType(e, MessagingException.class);
    if (t != null)
    {
        MessagingException me = (MessagingException) t;
        handleMessagingException(me.getMuleMessage(), e);
        return;
    }

    t = getExceptionType(e, LifecycleException.class);
    if (t != null)
    {
        LifecycleException le = (LifecycleException) t;
        handleLifecycleException(le.getComponent(), e);
        return;
    }

    handleStandardException(e);
}

Issue Links

is duplicated by

Patch submission - User code to be reviewed and incorporated into the product. MULE-4840 Exception message sent twice to the outbound endpoint defined in the exception strategy

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Patch submission - User code to be reviewed and incorporated into the product. MULE-4821 Exception message sent twice to the outbound endpoint defined in the exception strategy

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Edu Pereda made changes -
Field Original Value New Value
Link This issue blocks EE-1980 [ EE-1980 ]
epere4
14/Jul/10 02:50 PM
View full commit
MULE-4960: The AbstractExceptionListener handles the LifecycleException twice Removed the part that was handling LifecycleException as a MessagingException. git-svn-id: https://svn.codehaus.org/mule/branches/mule-2.2.x@18222 bf997673-6b11-0410-b953-e057580c5b09
mule-2.2.x
-
-9
core/src/main/java/org/mule/AbstractExceptionListener.java
Edu Pereda made changes -
Priority To be reviewed [ 6 ] Critical [ 2 ]
Edu Pereda made changes -
Status Open [ 1 ] In Progress [ 3 ]
Hide
Permalink
Edu Pereda added a comment -

Committed the change in 2.2.x.

http://fisheye.codehaus.org/changelog/mule/?cs=18222

Show
Edu Pereda added a comment - Committed the change in 2.2.x. http://fisheye.codehaus.org/changelog/mule/?cs=18222
Edu Pereda made changes -
Status In Progress [ 3 ] Open [ 1 ]
Edu Pereda made changes -
Status Open [ 1 ] In Progress [ 3 ]
Edu Pereda made changes -
Fix Version/s 2.2.6 (EE only) [ 10813 ]
Hide
Permalink
Edu Pereda added a comment -

This needs to be merged to 3.x

Show
Edu Pereda added a comment - This needs to be merged to 3.x
Edu Pereda made changes -
Status In Progress [ 3 ] To Be Merged [ 10001 ]
Hide
Permalink
Mateo Almenta Reca added a comment -

We need to make sure this is done before 3.0 CE.
Please sync-up with Ross on this one, since he re-implemented some of the life cycle handling

Show
Mateo Almenta Reca added a comment - We need to make sure this is done before 3.0 CE. Please sync-up with Ross on this one, since he re-implemented some of the life cycle handling
Mateo Almenta Reca made changes -
Labels 30CE Review
Mateo Almenta Reca made changes -
Labels 30CE Review Review
Mateo Almenta Reca made changes -
Labels Review 30CE_REVIEW Review
Mateo Almenta Reca made changes -
Labels 30CE_REVIEW Review 30CE_REVIEW
epere4
01/Sep/10 05:07 PM
View full commit
Merged revisions 18222,18615 via svnmerge from https://svn.codehaus.org/mule/branches/mule-2.2.x ........ r18222 | epere4 | 2010-07-14 16:50:48 -0300 (mié, 14 jul 2010) | 2 lines MULE-4960: The AbstractExceptionListener handles the LifecycleException twice Removed the part that was handling LifecycleException as a MessagingException. ........ r18615 | epere4 | 2010-07-28 18:46:09 -0300 (mié, 28 jul 2010) | 2 lines EE-1968 Exception strategy invoked twice Added an integration test that validates that exception strategy is only invoked once and only on the connector (ie. not the service exception strategy) when there is an exception on the outbound transformer (either if the outbound is sync or async). ........ git-svn-id: https://svn.codehaus.org/mule/branches/mule-3.x@19288 bf997673-6b11-0410-b953-e057580c5b09
3.1.x
-
-9
core/src/main/java/org/mule/exception/AbstractMessagingExceptionStrategy.java
Mike Schilling made changes -
Link This issue relates to BL-186 [ BL-186 ]
Travis Carlson made changes -
Status To Be Merged [ 10001 ] Closed [ 6 ]
Fix Version/s 3.0.0-RC3 [ 10874 ]
Resolution Fixed [ 1 ]
Travis Carlson made changes -
Link This issue is duplicated by MULE-4821 [ MULE-4821 ]
Travis Carlson made changes -
Link This issue is duplicated by MULE-4840 [ MULE-4840 ]
Hide
Permalink
Travis Carlson added a comment -

Merged to 3.x:
http://fisheye.codehaus.org/changelog/mule/?cs=19288

Show
Travis Carlson added a comment - Merged to 3.x: http://fisheye.codehaus.org/changelog/mule/?cs=19288
Transition Time In Source Status Execution Times Last Executer Last Execution Date
In Progress In Progress Open Open
1m 38s 1 Edu Pereda 14/Jul/10 02:53 PM
Open Open In Progress In Progress
23h 18m 2 Edu Pereda 15/Jul/10 01:06 PM
In Progress In Progress To Be Merged To Be Merged
1m 8s 1 Edu Pereda 15/Jul/10 01:07 PM
To Be Merged To Be Merged Closed Closed
49d 23h 7m 1 Travis Carlson 03/Sep/10 12:14 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-4960, p4JobFixed=MULE-4960, rep=mule}, methodType=GET}] : java.net.UnknownHostException: foo.bar

People

  • Assignee:
    Edu Pereda
    Reporter:
    Edu Pereda
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: