CommandHandler annotated with `@CreationPolicy` doesn't work if a no-arg constructor is missing

[lion7]

In my current project, I have an aggregate without a no-arg constructor (with a custom AggregateFactory registered).
Recently we added an upsert command that either creates or updates an aggregate. For this to work we shifted from using a constructor annotated with @CommandHandler to a method which was additionally annotated with @CreationPolicy(AggregateCreationPolicy.CREATE_IF_MISSING).

Unfortunately the AggregateAnnotationCommandHandler always assumes a no-arg constructor to be present in this case. It would be nice if the existing AggregateFactory would be used instead (or the ability to register a dedicated factory for this case?).

https://github.com/AxonFramework/AxonFramework/blob/8ea8532578a98aafd15ebb94534d27b2e60fa703/modelling/src/main/java/org/axonframework/modelling/command/AggregateAnnotationCommandHandler.java#L147-L161

P.S. in our case, only the aggregateIdentifier itself is needed to construct the aggregate instance. So our factory completely ignores the firstEvent provided in the constructor.
As an alternative, maybe a more generic firstMessage (command or event) could also be an option? There already exists an DomainEventMessage which extends a regular EventMessage with a method String getAggregateIdentifier();. Maybe something similar could also be done for CommandMessages?
In either case, it would be nice to have more control of how an aggregated is created.

[sandjelkovic]

Hey @lion7

Thanks for bringing this issue up!

The No-Arg constructor has been a requirement for a long time in the framework and still is, but as you discovered you can sometimes override it via Aggregate Factory. That's where the assumption came for directly using ::newInstance

At the point of creating aggregates for Create if missing, is not that trivial to use the AggregateFactory for a couple of reasons - one of them being dependencies as those classes are located in different modules.

We'll look into some approaches on how to make this possible, thanks for the suggestions!

The no-arg constructor rule has been in place for a while now, and we have looked into providing alternatives and allowing different types of factories for aggregates. It is something that we definitely want to do at some point.

There's been a similar attempt to provide similar functionality for immutable identifiers in the Kotlin extension, although a lot of the functionalities should be present in the core framework. You can find the discussion here if you're interested.