How to specify custom CommandTargetResolver with Spring Boot configuration in 4.5

I’m trying to supply a custom CommandTargetResolver in order to be able to use alternative annotations to mark up commands (trying to make it possible to have a domain module in pure Java, without external dependencies).

I have been pointed to an example that does something like this, but it does not use Spring Boot for configuration.

We probably need to change more wiring configuration along the way, so I’m interested in getting started off in the right direction (e.g. is the spring wiring flexible enough or would it be more efficient to just use the axon configuration system directly).

After poking a bit around in the code I stumbled upon ConfigurerModule but it is not obvious to me, how to replace the command target resolver using a configurer module, so maybe that is not the correct approach for this after all.

If anyone can point me in the right direction, it would be much appreciated, thanks.

Hi Chris,

if I understand correctly, you’re on Spring Boot? If that’s the case, all you need to do is define a bean of type CommandTargetResolver in your application context. Axon will use that one when it finds it.

If you need full customization, you can define your own AggregateConfigurer. You can define a bean returning a “ConfigurerModule” in your Spring Boot Application config. It has 1 method, which you need to implement. In that implementation, build the AggregateConfigurer instance as you wish to define your aggregate, and then register it with the Configurer, which is passed as the parameter to that method.

For example:

@Bean
public ConfigurerModule myAggregateConfiguration() {
    // since it has only one method, we can use a lambda    
    return configurer -> {
        configurer.configureAggregate(AggregateConfigurer.defaultConfiguration(MyAggregate.class));
    }
}
```

We are currently prototyping so this first attempt is just using boot to get going fast.

Reasoning about how spring and the axon config system fits together is a bit overwhelming at this point, so I just wanted to make sure that we take the right direction. In the spring code I stumbled upon the AggregateConfigurer was created using AggregateConfigurer.defaultConfiguration() without consulting spring - but I guess that something else plugs in the correct instance somewhere else.

The ConfigurerModule approach didn’t seem quite right, as I would like to avoid calling it for all aggregates (part of why I asked here).

I’ll try to override the aggregate configurer as suggested, it sounds like a good solution.