Snapshotter not configured with Axon Spring Boot Starter
See original GitHub issueWhen defining a custom SnapshotTriggerDefinition the docs: https://docs.axoniq.io/reference-guide/1.3-infrastructure-components/spring-boot-autoconfiguration#aggregate-configuration
State that:
Note that a Snapshotter instance, if not explicitly defined as a Bean already, will be automatically configured for you. This means you can simply pass the Snapshotter as a parameter to your SnapshotTriggerDefinition.
However, when I try the exact example in the docs I get the following:
2018-12-18 15:11:02.731 ERROR 52459 --- [ main] o.s.b.d.LoggingFailureAnalysisReporter :
***************************
APPLICATION FAILED TO START
***************************
Description:
Parameter 0 of method eventCountSnapshotTriggerDefinition in gamesys.general.demo.axon.conf.AxonDemoConfiguration required a bean of type 'org.axonframework.eventsourcing.Snapshotter' that could not be found.
Everything else works as expected, repositories etc. are all auto-configured. Have i set something up incorrectly, or is the documentation out of date?
Axon version: 3.4.2 (+axon-mongo 3.4.2) Spring boot version: 2.0.5.RELEASE
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Spring Boot AutoConfiguration - Axon Reference Guide
Note that a Snapshotter instance, if not explicitly defined as a Bean already, will be automatically configured for you. This means you can...
Read more >NoHandlerForCommandException with axon-spring-boot-starter
The commands that creates a new Aggregate instance should be placed on a constructor. The is no instance to invoke the method on,...
Read more >Implementing Event Snapshots in Axon 3 - Google Groups
Axon isn't currently using your defined "Repository<Sale>", but an autoconfigured one. ... if you're using Spring Boot with the Axon Spring Boot Starter, ......
Read more >Event Sourcing with Spring Boot and Axon | Novatec
You cannot change the past, therefore you should not validate or reject events. ... Then add the Axon dependencies(axon-spring-boot-starter, ...
Read more >A pragmatic design for an Axon system | by Niel de Wet
Simply include the axon-spring-boot-starter dependency and you're ready to go. ... I do not recommend creating a configuration using the @EnableAxon ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi,
After interacting with @smcvb I realized what is wrong.
I did some debugging, but did figure out why your
SnapshotTriggerDefinition
wasn’t set on your GiftCard Aggregate. The issue relates to the follow JavaDoc present on the@Aggregate
anotation:Now, I know you didn’t utilized the
@Aggregate#repository
field, but I did notice you created your ownCachingEventSourcingRepository
in theGcCommandConfiguration
class. The name Axon will configure an Aggregate’s repository defaults to{aggregate-name}Repository
. As the bean name of theCachingEventSourcingRepository
in that configuration class isgiftCardRepository
, the framework’s configuration API thinks you’ve specified a repository for the aggregate yourself (which granted, you did).Due too this, the
SnapshotTriggerDefinition
you defined in theAxonConfig
was not taken into account by the configuration API, resulting in the behavior you’ve encountered. I verified this was the problem by dropping theGcCommandConfiguration
and starting up your sample application again. After that and after creating a GiftCard through the UI and issuing some redeem operations, I correctly saw theSnapshotTriggerDefinition
taking effect.Concluding, if you want to configure both a caching repository and a snapshot trigger definition, you will be inclined, regardless, to use the
AggregateConfigurer
correctly.Added, I feel the JavaDoc of the
@Aggregate
annotation should specify that an existing bean corresponding to the default naming strategy will also trigger the behavior of a SnapshotTriggerDefinition not to be taken into account.Thanks for sharing our private discussion on this @gustavomr, pretty sure others will benefit from this too. Added, I have updated the JavaDoc top specify this point we’ve discovered, hopefully serving as an additional pointer for framework users, which can be found in this commit.