CODEWITHSUNDEEP
javaspringspring-integrationspring-integration-dsl
alturkovic
alturkovic

Reputation: 1120

Catching Spring Integration DSL misconfiguration exceptions?

Is there a way to catch DestinationResolutionException and MessageDispatchingException when using DSL? These exceptions usually indicate misconfiguration but I am not sure how I could configure my flow to catch these exceptions and apply some custom logic?

@SpringBootApplication
public class IntegrationMisconfigurationExampleApplication {
  public static void main(final String[] args) {
    SpringApplication.run(IntegrationMisconfigurationExampleApplication.class, args);
  }

  @Bean
  public IntegrationFlow loggingFlow() {
    return IntegrationFlows.from("input")
        .<String, String>transform(String::toUpperCase)
        // .nullChannel();
        .get();
  }

  @Bean
  public CommandLineRunner demo() {
    return args -> {
      final MessagingTemplate template = messagingTemplate();
      template.convertAndSend("input", "abc");
    };
  }

  @Bean
  public MessagingTemplate messagingTemplate() {
    return new MessagingTemplate();
  }
}

The example above throws a DestinationResolutionException because loggingFlow.transformer#0 is not properly initialized. Is there a way to catch this exception?

Upvotes: 1

Views: 96

Answers (1)

Artem Bilan
Artem Bilan

Reputation: 121262

Those exceptions are runtime errors. We really can't determine a misconfiguration at startup.

The way to catch runtime exception like that and do some analyzing work is with the ExpressionEvaluatingRequestHandlerAdvice, which you can add to your transform(String::toUpperCase) configuration in the second argument for endpoint configuration:

.<String, String>transform(String::toUpperCase, e-> e.advice(myExpressionEvaluatingRequestHandlerAdvice()))

See more info about this advice in the Reference Manual: https://docs.spring.io/spring-integration/docs/current/reference/html/#message-handler-advice-chain

Also you need to keep in mind that transformer is really a request-reply component with required non-null return value. Therefore you really can't configure a transform() just for one-way flow. It is going to throw an exception when there is no next channel in the flow or no replyChannel header in the message.

Upvotes: 1

Related Questions