-
15. Re: Cancelling a task fires task-end event
Actually, cancelling needs to be addresses in a much broader and general sense.
The loose term of cancel applies to many scenarios. From what I can see few of which are well defined
* cancelling a process definition
- cascading to process instance or not
- allowing running instances to terminate gracefully or not
* cancelling a process instance
- implicit cancelling through RuntimeException
- explicit cancelling through user exception
- model defined error flow
- model defined compensation flow
* cancelling of single task instance
- general support for multiple task instance
Also, how does an error during signal and message processing affect the process instance i.e. should the process be cancelled or not.
The above is merely a loose collection of related topics without the claim for completeness. The scope of cancel support can be defined for 1-Jan. However, please beware that there are much more basic and urgent topics to be covered. -
16. Re: Cancelling a task fires task-end event
"jbarrez" wrote:
(Hijacking the thread again :p)
Accepted"jbarrez" wrote:
Ronald, is it possible to make a blog post about it or was it for a customer? I'm interested in seeing your approach ... perhaps we can exchange our ideas?
working on it, escalating tasks was part of it... not all will be in there since it would become to complex, but it is another nice example that you can do lots of things with jBPM with small amounts of additional code"jbarrez" wrote:
eg. we had to create a special actorId 'parser' by using a 'role:assigned_to' string: if the assigned_to it meant that no-one was working on it, else the task is visible to anyone of the role.
Hmm.... we could just use pooled actors (which were group/role names). If you want to discuss this more easily, contact me on aol/msn/skype, is all in my profile -
17. Re: Cancelling a task fires task-end event
"kukeltje" wrote:
Still.... I get the feeling that extending the 'task handling process' a little is not wrong, but making it really configurable is imo well.. not realy a waste of time, but certainly not high priority... what we have is not that wrong. Putting two eventhandlers on a definition is supported *now*, making it configurable takes a lot of time
bull needed task lifecycle pluggability and it was not that hard. if we want to go far in ease of use, then things could get more complicated.
probably it will be easier to just add the pluggability and agree upon a default then agree whether a cancellation implies a task-end... -
18. Re: Cancelling a task fires task-end event
"thomas.diesler@jboss.com" wrote:
Another threadjack??? hmmm...hahaha... but... good discussions upfront, so everybody can let it sink in and think about it
Actually, cancelling needs to be addresses in a much broader and general sense."thomas.diesler@jboss.com" wrote:
...is merely a loose collection of related topics without the claim for completeness. The scope of cancel support can be defined for 1-Jan. However, please beware that there are much more basic and urgent topics to be covered.
I agree but you'll see there is a closer relation between the items you mention and the api, the language etc... Focussing just on the basics can make (j)BPM look over simplified.. -
19. Re: Cancelling a task fires task-end event
Agree, it's API stuff. But I was referring to this
Questions were more about declaring vars, typing them, giving default values etc
My concern was more about granularity of the discussion. I.e. Thomas reply is more likely what I consider an appropriate level to have a discussion at the team meeting.
Does that make sense? -
20. Re: Cancelling a task fires task-end event
instead of hijacking this thread (which i'm now doing anyway:-) i have hijacked a completely new topic for the meeting context.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180766#4180766 -
21. Re: Cancelling a task fires task-end event
Yes it does, but with
Questions were more about declaring vars, typing them, giving default values etc
I was not stating that this should be the main subject of the meeting, not at all (although we should address it to some extend). I was just stating that almost no one asked for more support of patterns. They most likely could manage their use-cases with what jBPM provides. -
22. Re: Cancelling a task fires task-end event
bull needed task lifecycle pluggability and it was not that hard. if we want to go far in ease of use, then things could get more complicated.
probably it will be easier to just add the pluggability and agree upon a default then agree whether a cancellation implies a task-end...
Plugability fine... making an extensively configurable first implementation not. Unless maybe we eat your own dogfood and Implement it as a 'subproces'? But how would that reflect than in an api? -
23. Re: Cancelling a task fires task-end event
Did the task-cancel event ever make it into the codebase? Our client needs this.
Thanks,
Brad -
24. Re: Cancelling a task fires task-end event
in 3.2/3.3 no, but you might be able to use the task-end event (which is 'raised' and check if it was caused by a cancel or an end. Not sure though