This is another implementation of #154, where the user can define the compaction key extractors as spring beans, instead of using a register function on the event log writer (as was done in #158).
This seems to be a more spring-y way of doing this.
Doing this also gave the need/opportunity to rewrite the internal logic of finding the right extractor.
Opinions please: is this better or worse than the way in #158?
(Most of the commits are the same as in #158, the last ones are the new ones.)
For the change log:
164: support compacted event types (via spring beans)
You now can fire events for a compacted event type, by adding a CompactionKeyExtractor spring bean.
I plan to make two variant release candidate builds with both options, so I can try this out in an actual project where the need for this arose. (But I'm not sure whether I can get to this this week.)
This is another implementation of #154, where the user can define the compaction key extractors as spring beans, instead of using a register function on the event log writer (as was done in #158).
This seems to be a more spring-y way of doing this.
Doing this also gave the need/opportunity to rewrite the internal logic of finding the right extractor.
Opinions please: is this better or worse than the way in #158?(Most of the commits are the same as in #158, the last ones are the new ones.)
For the change log:
164: support compacted event types (via spring beans)
You now can fire events for a compacted event type, by adding a CompactionKeyExtractor spring bean.