4.11.0 InterceptorAutoConfiguration create circular dependencies

Axon Framework
1

I updated from 4.10.3 to 4.11.0 and noticed it breaks existing configurations from cycle detection. I realize everyones customizations are different, but in general I get something like the following

The dependencies of some of the beans in the application context form a cycle:

   restCommandController defined in file [repos/digital-engineering-starter-axon/digital-engineering-starter-axon-rest/build/classes/java/main/com/deng/axon/rest/commands/RestCommandController.class]
      ↓
   restCommandBusConnector defined in class path resource [com/deng/axon/rest/config/RestAxonAutoConfig.class]
┌─────┐
|  commandBus defined in class path resource [org/axonframework/springboot/autoconfig/AxonAutoConfiguration.class]
↑     ↓
|  springAxonConfiguration
↑     ↓
|  commandGateway defined in class path resource [org/axonframework/springboot/autoconfig/AxonAutoConfiguration.class]
↑     ↓
|  distributedCommandBus defined in class path resource [com/deng/axon/distributed/config/DistributedAxonAutoConfig.class]
↑     ↓
|  unifiedCommandBusConnector defined in class path resource [com/deng/axon/distributed/config/DistributedAxonAutoConfig.class]
└─────┘

The culprit seems to be InterceptorAutoConfiguration. When I excluded it, everythings works as expected.

1 Like
2

Hi @cneuwirt,

Thank you for the report.

Unfortunately, this is a bug in version 4.11.0.
We’ve already identified the issue and will resolve it with a patch release.

You can follow this issue to track its progress: Auto-register `MessageHandlerInterceptors` with Spring Boot fails for interceptors which depends on Axon components · Issue #3283 · AxonFramework/AxonFramework · GitHub

Warm regards,
Mateusz

3

Hello Mateusz,

Thanks for the update. I actually checked the issues list after I created this comment and saw a bug listed.

1 Like
4

@cneuwirt, I would like to notify you that the referred to issue by @MateuszNowak has seen a PR, approval, and has been merged.

This means that there’s a 4.11.1-SNAPSHOT release of Axon Framework that contains the aforementioned fix.
If your time allows it, would you be open to test if this snapshot version resolve the issue you’re seeing?
We have, of course, tested it against our own sample projects. But knowing a project “in the field” is resolved also gives us the added certainty to proceed towards a patch release.

1 Like
5

We’ve validated the fix to work in several projects the last couple of days.
As such, we feel comfortable that the problem was resolved by issue #3283.

Hence, we’ve released Axon Framework 4.11.1 with that fix today.
Feel free to let us know if that release solves the problem you were seeing, @cneuwirt!

6

Hello Steven,

Thanks for the feedback. It did resolve my issue. Just to make sure, the interceptor auto-registration has no effect on existing registrations like

  commandBus.registerHandlerInterceptor( loggingInterceptor );
  commandBus.registerDispatchInterceptor( loggingInterceptor );

I did have to make a change to get things to work as expected. The following didn’t work anymore

@Aspect
@Component
@ConditionalOnBean( CommandGateway.class )
public class CommandHandlingAspect {

    private final CommandGateway commandGateway;

    public CommandHandlingAspect( CommandGateway commandGateway ) {
        this.commandGateway = commandGateway;
    }
...
}

With 4.11.1, the @ConditionalOnBean( CommandGateway.class ) prevented the aspect from getting created.

7

I answered my own question. I removed all explicit registerHandlerInterceptor and registerDispatchInterceptor calls which is a nice feature.

1 Like
8

Happy to hear you’re able to proceed with this, @cneuwirt!

9

Yes, all looks good at the moment. Do you have any idea why the configuration sequence no longer allows

@Aspect
@Component
@ConditionalOnBean( CommandGateway.class )
public class CommandHandlingAspect {

    private final CommandGateway commandGateway;

    public CommandHandlingAspect( CommandGateway commandGateway ) {
        this.commandGateway = commandGateway;
    }
...
}

My objective is to not able certain aspects if a gateway is not present.

10

To be frank with you, Craig, I don’t know why this ConditionalOnBean approach doesn’t work. Although I don’t think it should impact, I do want to ask if you have tried a bean creation method instead of annotating the class directly?

So, if you do what’s down below if the issue persists:

@Aspect
@Bean
@ConditionalOnBean(CommandGateway.class)
public CommandHandlerAspect commandHandlerAspect(CommandGateway commandGateway) {
    return new CommandHandlerAspect(commandGateway);
}

I don’t have direct experience with using the @Aspect annotation, nor does the Axon Framework project contain any tests if that annotation has an impact on the wiring process. So, I am also wondering whether removal of that annotation causes the ConditionalOnBean to work again, yes/no.

11

Hello Steven,

I am working on your request to move the aspects into a @Configuration class. However, I am noticing BeanValidationInterceptor is never getting applied to dispatch or handler interceptors. My configuration includes

 @Bean
    public LoggingInterceptor<Message<?>> loggingInterceptor() {
        return new LoggingInterceptor<>();
    }

    @Bean
    public BeanValidationInterceptor<?> validationInterceptor() {
        return new BeanValidationInterceptor<>();
    }

    @Bean
    public ResultsInterceptor<Message<?>> resultsInterceptor(
            ApplicationContext applicationContext
    ) {
        return new ResultsInterceptor<>( applicationContext );
    }

but only the LoggingInterceptor and ResultsInterceptor are getting passed to

InterceptorAutoConfiguration.commandDispatchInterceptorConfigurer

and

InterceptorAutoConfiguration.commandHandlerInterceptorConfigurer

Do you have any unit tests to verify BeanValidationInterceptor is properly included?

12

The BeanValidationInterceptor was my error, I was returning BeanValidatorInterceptor<?> instead of BeanValidationInterceptor>

13

Well, that can happen. Happy you found it :slight_smile:
To be frank, I am not sure whether your status on this issue is now done or not.
So, if there are still some lingering issues with auto-configuring dispatch- and handler-interceptors, be sure to let me know!

14

Oh sorry. You can definitely close any concerns I have. The only difference was the conditional aspect above and it was only in our unit tests so easy to resolve. Thanks for all your help.

1 Like