Hi Steven, no worries about that, I did added a smiley to my comment…
I noticed I didn’t explain why I want to replay events for Sagas, we actually do that for different reasons but in this case is just to recreate the internal state of the Saga. This happens when I change the Saga class itself and I have to update the serialized sagas. In certain cases like, say, having a property removed
// private int subtasks = 0;
if I still have it the serialized sagas I’ll get a error when loading. This particular scenario is easy to fix since a simple update with a XSLT identity transform will do. However, if I change something like
private Map subtasks = new HashMap<UUID, Boolean>();
private Map subtasks = new ConcurrentHashMap<UUID, Boolean>();
(actually my case is even more complicated since my map extends those)
This case is particularly tricky specially if the serialized map is already populated. So in this cases the best option (AFAIK) is to delete the Saga from the DB and recreate it by replaying events. Can you think of another way?
Your suggestion of having a service seems a overkill to this scenario, and would add too much unnecessary complexity, AFAICS. And also, the way we designed our “replayer” was with the intention of having a SagaManager/EventBus instantiated internally, and not the ones the application normally use, to allow us to pick and choose which Sagas/Eeven listeners we do want to replay to.
The other suggestion of having a ParameterResolver may be useful but to be frank that would need more investigation and I spend too much time looking at this, and I can kust use the current replayer with a AnnotatedSagaManager that until now only failed in a fringe situation of a Saga receiving events from two diferent sources.