Here are some pointers to EntityCallbacks. There are reactive and imperative ones complementing Lifecycle Events.
Docs (Scroll down to Entity Callbacks): https://docs.spring.io/spring-data/mongodb/docs/2.2.0.RC1/reference/html/#mongodb.mapping-usage.events
Imperative Callback API: https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/mapping/callback/EntityCallbacks.java#L50
Reactive Callback API: https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/mapping/callback/ReactiveEntityCallbacks.java#L53
Auditing Callback (MongoDB): https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/mapping/event/AuditingEntityCallback.java
Implementation (Imperative MongoDB): https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/MongoTemplate.java#L1276-L1286
The actual callback interfaces live within each store module because they typically depend on store-specific API.
Callbacks are modeled along the lines of ApplicationEventMulticaster, callback beans are picked up from the ApplicationContext.
This looks like the new boilerplate related to auditing
Hey Mark, is it fair to say the main motivation for using EntityCallbacks is regarding mutability of entities vs the older way of using the event publisher?
This looks like the new boilerplate related to auditing