Announcement Announcement Module
No announcement yet.
RuntimeException handling through <gateway> Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • RuntimeException handling through <gateway>

    I'm having some difficulty with handling exceptions. Using 2.0.0.M4.

    I'm using a Gateway to invoke a method on a bean with a service activator. That method throws an UnsupportedOperationException i.e. a RuntimeException.

    With a DirectChannel, the caller gets a MessageHandlingException with its cause set to the orginal UnsupportedOperationException.

    With a QueueChannel, the caller gets a ConversionNotSupportedException. Here's what happens...

    The UnsupportedOperationException gets sent back as an ErrorMessage down the SimpleMessagingGateway's MessageChannelTemplate's errorChannel.
    There is handling in SimpleMessagingGatewaty(AbstractMessageGateway).se ndAndReceiveMessage for specially handling an ErrorMessage by picking out its payload and rethrowing it. This isn't being invoked though because the MessageChannelTemplate.doSendAndReceive builds a new reply message (from the ErrorMessage) but that is not of type ErrorMessage. (In fact, I'm not sure that the reply message can ever be an instanceof ErrorMesssage because of this.) Back at GatewayProxyFactoryBean, it attempts to convert this response Message to the Gateway interface's return type. That fails because the payload of the response message is the exception, hence the ConversionNotSupportedException.

    I can't tell exactly what is at fault here. It could very well be me.

    Should MessageBuilder.fromMessage retain the type of the original message?
    Perhaps the ErrorMessage should be unpacked immediately on receipt and its exception rethrown?

    I have made a small testcase to demonstrate. Please see attached.
    Last edited by andyc; Jun 17th, 2010, 12:45 PM. Reason: Adding some further detail

  • #2
    This is worth a bug report. What you're trying to do is not unreasonable by any measure, it should not throw a ConversionNotSupportedException.


    • #3
      Please do submit this via JIRA:



      • #4
        Thanks for the responses. I've raised