Expections thrown from nested router are incorrectly unwrapped

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0.2
  • Fix Version/s: Bug Backlog
  • Component/s: Core: Routing / Filters
  • Labels:
    None
  • Environment:

    Linux/Ubuntu 8.04 Java Sun 1.6.0

  • User impact:
    High
  • Effort points:
    0.5
  • Similar Issues:
    None

Description

When an exception is thrown from a service which is called via a nested router, this exception is incorrectly delivered to the caller. Within Mule, this exception is wrapped in a ServiceException and transported over the Bus as an exception payload. Within the NestedInvocationHandler, the ServiceException itself is thrown to the caller. As ServiceException is a checked exception which is off course not declared on the interface implemented by the nested router, this results in a java.lang.reflect.UndeclaredThrowableException. The expected behaviour would be that the exception packed within the ServiceException would be thrown to the caller, as this exception is declared on the interface.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jeroen Benckhuijsen added a comment -

Attached a patch which fixes the issue by unwrapping the original exception package in the ServiceException

Show
Jeroen Benckhuijsen added a comment - Attached a patch which fixes the issue by unwrapping the original exception package in the ServiceException
Jeroen Benckhuijsen made changes -
Field Original Value New Value
Attachment NestedInvocationHandler.patch [ 11820 ]
Daniel Feist made changes -
Fix Version/s 2.0.x Backlog [ 10352 ]
Ross Mason made changes -
Priority To be reviewed [ 6 ] Critical [ 2 ]
Daniel Feist made changes -
Fix Version/s 2.x Backlog [ 10440 ]
Fix Version/s 2.0.x Backlog [ 10352 ]
Daniel Feist made changes -
Effort points 0.5
Daniel Feist made changes -
Fix Version/s 2.x Backlog [ 10440 ]
Fix Version/s 2.1.x Backlog Candidates [ 10559 ]
Daniel Feist made changes -
Fix Version/s 2.1.x (to be PO reviewed) [ 10559 ]
Fix Version/s 2.1.x Backlog [ 10522 ]
Daniel Feist made changes -
Assignee Daniel Feist [ dfeist ]
Hide
Permalink
Daniel Feist added a comment -

I agree some improvements need to be made around nested router exception handling but I think your fix will only help if a ServiceException is being returned by the remote service.

It seems the best approach might be to leave things as they are in the NestedInvocationHandler and slightly higher up in the DefaultLifecycleManager unwrap the UndeclaredThrowableException exception and throw it (possibly nested inside a BindingRoutingException). Any thoughts?

Show
Daniel Feist added a comment - I agree some improvements need to be made around nested router exception handling but I think your fix will only help if a ServiceException is being returned by the remote service. It seems the best approach might be to leave things as they are in the NestedInvocationHandler and slightly higher up in the DefaultLifecycleManager unwrap the UndeclaredThrowableException exception and throw it (possibly nested inside a BindingRoutingException). Any thoughts?
Hide
Permalink
Jeroen Benckhuijsen added a comment -

Wouldn´t that defy the whole point of being able to catch the thrown exceptions from the invoking code? You're right however that this only works in case the remote service throws a ServiceException, which isn't even the case always. I haven't tested it for all transports, but at least for JMS I can say that exceptions aren't returned at all to the caller, they are send to the default exception handler (which discards them into the log). For the VM-transport this works (as it is thrown form the same thread).

For my project we resorted to using a custom exception handler which would use the reply-to property of JMS to send the exception back to the caller. However that solution feels kinda hack-isch.

Anyway, I think we're dealing with two different scenarios when implementing the final solution: (1) we're just trying to bind an endpoint (e.g SMTP) to easily send data to that endpoint from Java code (e.g. a MailMessage to send an email) and (2) we're binding a remote component where Mule handles the actual transport that is used for communication (e.g. JMS, RMI, SOAP/HTTP, etc), a bit like SCA. The patch is meant for option 2 off course, can't really tell if it interferes with option 1 though.

Another issue with remote invocation (option 2) are RuntimeExceptions. We cannot send those back to the service as this may result in ClassNotFoundEx (e.g. one the called component uses Hibernate while the calling component doesn't). In my custom exception handler I would just send back a plain RuntimeException with the original stacktrace as message (based on the assumption that the invoking code can't do anything with any RE send back from the callee).

Show
Jeroen Benckhuijsen added a comment - Wouldn´t that defy the whole point of being able to catch the thrown exceptions from the invoking code? You're right however that this only works in case the remote service throws a ServiceException, which isn't even the case always. I haven't tested it for all transports, but at least for JMS I can say that exceptions aren't returned at all to the caller, they are send to the default exception handler (which discards them into the log). For the VM-transport this works (as it is thrown form the same thread). For my project we resorted to using a custom exception handler which would use the reply-to property of JMS to send the exception back to the caller. However that solution feels kinda hack-isch. Anyway, I think we're dealing with two different scenarios when implementing the final solution: (1) we're just trying to bind an endpoint (e.g SMTP) to easily send data to that endpoint from Java code (e.g. a MailMessage to send an email) and (2) we're binding a remote component where Mule handles the actual transport that is used for communication (e.g. JMS, RMI, SOAP/HTTP, etc), a bit like SCA. The patch is meant for option 2 off course, can't really tell if it interferes with option 1 though. Another issue with remote invocation (option 2) are RuntimeExceptions. We cannot send those back to the service as this may result in ClassNotFoundEx (e.g. one the called component uses Hibernate while the calling component doesn't). In my custom exception handler I would just send back a plain RuntimeException with the original stacktrace as message (based on the assumption that the invoking code can't do anything with any RE send back from the callee).
Daniel Feist made changes -
Priority Critical [ 2 ] Major [ 3 ]
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-3644, p4JobFixed=MULE-3644, rep=mule}, methodType=GET}] : java.net.UnknownHostException: foo.bar

People

  • Assignee:
    Daniel Feist
    Reporter:
    Jeroen Benckhuijsen
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: