every once in a while, I swap things around on this mailinglist. This time, it’s me asking the questions ;-).
As you might know (and if not, you’ll know from now on), you can use all sorts of parameters in @CommandHandler and @EventHandler annotated methods. If you use Spring, you can even use parameters where Axon will automatically inject Spring beans.
Recently, I had received feedback (mostly from OSGi users) that injecting the ParameterResolverFactory (ultimately responsible for providing the values to use in parameters) would be better than the current singleton approach. I have to agree with that and changes are on the way in 2.1.
There is one challenge, though: the Aggregates. Unlike all other components, creation of aggregates is not (always) managed by Axon. So, somehow, the Aggregate instance needs to get access to the handler mechanism by Axon.
I see a few options to make each Aggregate instance “aware” of the ParameterResolverFactory it should use: Note that this problem doesn’t occur on @CommandHandler methods in Aggregates, just the @EventHandler ones.
Use a singleton holder that keeps a reference to the ParameterResolverFactory for the aggregates to use (thus single instance per VM)
A variation of the above where an (additional) configuration can be provided per aggregate type
Have the Repository configure the right ParameterResolverFactory. The fact that these extra parameters aren’t available when creating an aggregate is not a problem.
Use the UnitOfWork to hold a reference to the ParameterResolverFactory instance to use while executing that command
Don’t worry about custom parameters. The default ones are good enough on Aggregate Event Handlers
I know another way: …
Note that options 1 through 4 will be automatically configured for Spring users when using <axon:annotation-config …>.
Please cast your votes.