Thank you for your quick reply, Ed.
Even though "at least token-specific" doesn't rule out "at most
ProcessInstance-specific", I tend to concur with you on this one. What you are
saying makes sense, especially when one analyses the fields of
ExecutionContext: Token, Event, Action, Node, Transition, etc. Also, one of the
two constructors only takes a Token as a parameter.
That being said, I think I can now manage to ask a more concrete question:
In one of the tutorials, the one with the task assignment, the task node is
defined like this:
[...]
| <task-node name='t'>
| <task name='change nappy'>
| <assignment class='[...].NappyAssignmentHandler'>
| </task>
| </task-node>
| [...]
Then, the token starts moving through the workflow, arrives at our task node t.
Then, a TaskInstance object is created and... _then something magic happens_
... and the actor we specified in the implementation of NappyAssignmentHandler
appears to be a field of our TaskInstance (actorId), even though the only thing
we did in NappyAssignmentHandler was this:
public void assign(Assignable assignable, ExecutionContext executionContext){
| assignable.setActorId("papa");
| }
I don't see any direct assignment of "papa" to TaskInstance.actorId happening
anywhere. Nor do I see any indirect, multi-stage version of this assignment.
And anyway, how the hell did the executionContext or the assignable Parameters
get their values? Was this done by the XML Parser? Is the ExecutionContext
relevant for the values of TaskInstance fields? Or am I on the completely wrong
path here?
I'd really appreciate it if someone would explain to me how these "magic
tricks" are performed.
Thanks for reading!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153846#4153846
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153846
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
