Spring Integration
  1. Spring Integration
  2. INT-907

Implement proper exception handling for message driven channel adapters (synchronous handling / within transaction)

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Complete
    • Affects Version/s: 1.0.3
    • Fix Version/s: 2.0 M5
    • Component/s: Core
    • Labels:
      None

      Description

      See forum discussion for background. I think it would be nice to have the same possibility while using synchronous message handling / DefaultMessageListenerContainer.
      If not the message will just roll back and forward endlessly.
      It's possible to override the DefaultMessageListenerContainer - but this will not provide the original Spring Integration Message along with the exception.

        Issue Links

          Activity

          Hide
          Jess Sightler added a comment -

          @Mark - Good points... I agree that this would be a workable solution for me.

          Show
          Jess Sightler added a comment - @Mark - Good points... I agree that this would be a workable solution for me.
          Hide
          Gérald Quintana added a comment -

          @Mark: You are completely right

          Show
          Gérald Quintana added a comment - @Mark: You are completely right
          Hide
          Oleg Zhurakousky added a comment -

          Support for pluggable exception handling strategies is now provided vi pluggable message mappers via exception-mapper attribute on <gateway> and <int-jms:inbound-gateway> and is based on a simple mechanism which allows you to catch exception do something with it and output a successful message. In JMS case his message will be sent to JMSReply destination and in a case of regular gateway it will result in successful invocation of Gateway method.
          Here is simple configuration:

          JMS:

          <int-jms:inbound-gateway request-destination="requestQueue" 
                                   request-channel="jmsinputchannel"
                                   exception-mapper="errorMessageMapper"/>
          
          <bean id="errorMessageMapper" class="org.springframework.integration.jms.config.ExceptionHandlingSiConsumerTests$SampleErrorMessageMapper"/> 
          
          public static class SampleErrorMessageMapper implements InboundMessageMapper<Throwable>{
          	public org.springframework.integration.core.Message<?> toMessage(
          				Throwable t) throws Exception {
                          // do something wit the Exception and return the message
          		return MessageBuilder.withPayload(t.getCause().getMessage()).build();
          	}
          }                   
          

          Regular Gateway:

          <si:gateway id="gatewayWithErrorAsyncAndMapper"
          	default-request-channel="routingChannel" 
          	service-interface="org.springframework.integration.gateway.GatewayInvokingMessageHandlerTests$SimpleGateway"
          	exception-mapper="exceptionMapper"/>
          . . .
          

          For more details please look at the following test cases:
          JMS:
          ExceptionHandlingSiConsumerTests
          ExceptionHandlingSiConsuerTests-context.xml

          Regular Gateway (which also includes async as well sync invocation samples)

          GatewayInvokingMessageHandlerTests
          GatewayInvokingMessageHandlerTests-context.xml

          Show
          Oleg Zhurakousky added a comment - Support for pluggable exception handling strategies is now provided vi pluggable message mappers via exception-mapper attribute on <gateway> and <int-jms:inbound-gateway> and is based on a simple mechanism which allows you to catch exception do something with it and output a successful message. In JMS case his message will be sent to JMSReply destination and in a case of regular gateway it will result in successful invocation of Gateway method. Here is simple configuration: JMS: < int -jms:inbound-gateway request-destination= "requestQueue" request-channel= "jmsinputchannel" exception-mapper= "errorMessageMapper" /> <bean id= "errorMessageMapper" class= "org.springframework.integration.jms.config.ExceptionHandlingSiConsumerTests$SampleErrorMessageMapper" /> public static class SampleErrorMessageMapper implements InboundMessageMapper<Throwable>{ public org.springframework.integration.core.Message<?> toMessage( Throwable t) throws Exception { // do something wit the Exception and return the message return MessageBuilder.withPayload(t.getCause().getMessage()).build(); } } Regular Gateway: <si:gateway id= "gatewayWithErrorAsyncAndMapper" default -request-channel= "routingChannel" service- interface = "org.springframework.integration.gateway.GatewayInvokingMessageHandlerTests$SimpleGateway" exception-mapper= "exceptionMapper" /> . . . For more details please look at the following test cases: JMS: ExceptionHandlingSiConsumerTests ExceptionHandlingSiConsuerTests-context.xml Regular Gateway (which also includes async as well sync invocation samples) GatewayInvokingMessageHandlerTests GatewayInvokingMessageHandlerTests-context.xml
          Hide
          anand added a comment -

          Hi,

          The ExceptionMapper is a good solution. Is there any way so that the message can be referenced in the ExceptionMapper using above approach ? Assuming that the end point itself threw the exception and the end-point even does not have access to the original message which was received by JMS inbound adapter( This will happen when message has undergone various transformations before reaching the end-point). This requirement is there because the exception mapper may need to know the original message to create a response.

          Show
          anand added a comment - Hi, The ExceptionMapper is a good solution. Is there any way so that the message can be referenced in the ExceptionMapper using above approach ? Assuming that the end point itself threw the exception and the end-point even does not have access to the original message which was received by JMS inbound adapter( This will happen when message has undergone various transformations before reaching the end-point). This requirement is there because the exception mapper may need to know the original message to create a response.
          Hide
          vinay sambyal added a comment -

          Hi Oleg,
          I am not able to see the sample test for which you have given the links. link is broken. Can you please put the upadted link.

          ExceptionHandlingSiConsumerTests
          ExceptionHandlingSiConsuerTests-context.xml

          Thanks

          Show
          vinay sambyal added a comment - Hi Oleg, I am not able to see the sample test for which you have given the links. link is broken. Can you please put the upadted link. ExceptionHandlingSiConsumerTests ExceptionHandlingSiConsuerTests-context.xml Thanks

            People

            • Assignee:
              Oleg Zhurakousky
              Reporter:
              David J. M. Karlsen
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: