Ronald, If you are using this construction: | if (this.isCancelled) { | task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext); | } else { | task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext); | } | Then you are missing the TASK_END event if the task is cancelled. People for who see 'finishing a task ' (ie. cancelling or completing) as the end of a task (which is conceptually also correct) and now simply use an event handler for the TASK_END event are obliged to use 2 event handlers now. So it comes down to a matter of conceptual view: - Ending a task == the task is finished (removed by cancelling or successfully completed) - Ending a task == completing the task successfully, BUT cancelling means here that the task did not end but simply dissapeared for some reason. I have implemented both use cases in the past, so this is not some academic example. What we need here is a solid and clear definition ... anonymous wrote : | Otoh, I've not heard people complaining about taskmanagement regarding the 'states' of task management do you guys? Questions were more about declaring vars, typing them, giving default values etc | That's true ... but I did have a use case in which the states of a task were THE most import thing: cancelled, suspended, ended, assigned but not taken, working on it, etc. all those states were possible for a task. So you can imagine I would have been very happy at that moment if I had some more options ... we had to juggle a bit with task variables to get it all done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180733#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...