the real solution is to implement it in the BPMN activity base class.
add a method to the BpmnActivity like leaveBpmnActivity(ExecutionImpl execution)
changing the pvm in this respect is not desirable. the generic behaviour of the proceed is something that i think over time should be faded out. activities should be explicit in what they want to see happening. combined default behaviour like in the proceed is always process language specific. so it doesn't belong in the pvm proceed. it belongs in the process language specific base classes.
(ps you already might have noticed that in our own implementations, it is best to use the impl classes and not the interfaces)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246857#4246857
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246857
wow, we have a noob here in the forum... ;-)
Yes, sounds logical. But this means that signalling via the api should set this variable? or can we have an additional solution that if there is a textual (non formal) condition that when signalling flow name/id is used.
I can implement anything like this, but it has to be very specific. Including things like what if there is no flow that has a condition that evaluates to true. etc...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246843#4246843
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246843
"camunda" wrote : P.S: I commit a failing test case with a uncontrolled sequence flow as Fork and two tasks, if somebody cannot stop himself from coding ;-)
|
If this test was the only thing failing ;-)
- dueDate -> duedate, but named queries not updatred jbpm.execution.hbm.xml : Koen
- AbstractTaskBinding in jbpm.bpmn.flownodes.xml which does not exist (yet?) : Bernd
And the strange thing is, I do not see hudson failing yet...Or is there a delay?
Oh... I take up the challenge... coding continues
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246827#4246827
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246827
Maybe it is a good idea for the time-being to just make it work and file a jira issue for a real solution. That way it can work for everybody by using the source, but the issue is not forgotten.
And now we are into languages anyway:
"als het niet kan zoals het moet, dan moet het maar zoals het kan" is what we say in Dutch. (finding a proper translation I came across: if it ain't dutch it ain't much. Something completely different, but just as true) 1 Heineken for each proper translation as google fails miserably
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246786#4246786
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246786
Hi.
Just wanted to write it down for now: Since BPMN defines more than one outgoing flow as AND-Split (fork), this applies to the UserTask as well.
This means, the XOR semantic from jPDL, where the user selects a outgoing transition, cannot be applied here. In my opinion it must be modelled as conditions on the flow (assume we have Java Expression Language):
#{outcome == "ok"}
#{outcome == "cancel"}
Now the outcome can be set by the task management like in JPDL and it works the same.
Sounds logical?
Cheers
Bernd
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246756#4246756
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246756