Greetings. I think some clarity is needed on the doc page describing the java Workflow Interface. It should be made clear that when using signals, it is important to use the factory pattern for creating workflow instance implementations, i.e. Worker#addWorkflowImplementationFactory(…). The other workflow examples register just a singleton implementation, which isn’t going to work with signals (although it might be possible to hack it with nasty thread-locals). Also, it’s not clear what the scoping of the addWorkflowImplementationFactory(…) is. I assume it would be to each individual workflow call. Full disclosure, I haven’t tried coding this case yet (we’re fighting with it in SWF), but will hopefully try later today (using Spring). Many thanks!
I don’t understand the question.
addWorkflowImplementationFactory should not be used at all unless you are doing framework level integrations or unit testing. Signals do work fine when using Worker.registerWorkflowImplementationTypes. Look at the sample that demonstrates this.
Greetings. Sorry for the late reply. I haven’t yet sat down and attempted a Spring integration. But . . .
The method addWorkflowImplementationFactory(…) might be useful as it would allow you to create new on-demand Spring beans. That is, unless something is integrated at a lower level to create the bean when the class instance is being created.
Note, this is not the same for activities. In the Java API at least, only singletons are supported. There is no (i) registerActivityImplementationTypes(…) or (ii) addActivityImplementationFactory(…). Surely, at a minimum, we need (i)?
UPDATE: just read the following comment: “Register activity implementation objects with a worker. Overwrites previously registered objects. As activities are reentrant and stateless only one instance per activity type is registered.”
I guess that answers the question then. 
Many thanks,
Sean