[JBoss JIRA] Created: (JBPM-2975) problem with Fork/Join
by doublehero Xu (JIRA)
problem with Fork/Join
----------------------
Key: JBPM-2975
URL: https://jira.jboss.org/browse/JBPM-2975
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.2
Reporter: doublehero Xu
Hi,I have get a problem in using the JBPM framework, the version of JBPM framework is 4.2 . You can copy my junit test files into your project and run the AsyncForkTest class as a junit test application, the test result won't be passed.So what just happen?
ps.I have another question,Is it a necessary to use a Fork and Join tag at the same time in the xxx.jpdl.xml? Cause in my junit test , I only use the Fork tag.
Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2976) Order of child executions for fork is non-deterministic
by Mike M (JIRA)
Order of child executions for fork is non-deterministic
-------------------------------------------------------
Key: JBPM-2976
URL: https://jira.jboss.org/browse/JBPM-2976
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4
Reporter: Mike M
In 4.4, the implementation of the ForkActivity was changed such that a map (Transition -> Child Execution) is now built. Because this is just a generic map without any ordering, the actual order in which the child executions get executed is now non-deterministic. In 4.3, the order was always the same as the order in which the outgoing transitions were listed in the process definition.
Now, I'm not sure if this side-effect (making the order non-deterministic) was intentional or not but it definitely break things when other parts of the workflow rely upon a specific ordering. There are definite, real use cases where it is necessary and desirable to specify an explicit order for things.
Our workaround was to create a custom activity that is basically exactly the same as ForkActivity, but orders the taking of transitions on child executions so that it is the same as defined in the process definition.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2977) NPE in HistoryActivityInstanceImpl ctor when Activity is null
by Mike M (JIRA)
NPE in HistoryActivityInstanceImpl ctor when Activity is null
-------------------------------------------------------------
Key: JBPM-2977
URL: https://jira.jboss.org/browse/JBPM-2977
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.4
Reporter: Mike M
In 4.4, automatic history recording was added for custom activities (JBPM-2495). In order to work around (JBPM-2976), we had to create a custom activity that was basically the ForkActivity with slight modification. In the jbpm implementation of the ForkActivity (on which ours was based), it sets the Activity of the root execution to null before launching child executions. When the process engine later executes the history code, the constructor for HistoryActivityInstanceImpl fails with an NPE because the activity is null.
Our workaround is to comment out the line in our Fork implementation that sets the Activity to null. Not sure if this has any side effects, but we haven't seen any so far.
Now granted, it is a rather odd case to have a custom activity setting the activity to null. But nonetheless, it seems that a generic history mechanism should handle this case gracefully, rather than just throwing an NPE.
Our
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-1170) Multiple Timers with same name on Node end prematurely
by David Roberts (JIRA)
Multiple Timers with same name on Node end prematurely
------------------------------------------------------
Key: JBPM-1170
URL: http://jira.jboss.com/jira/browse/JBPM-1170
Project: JBoss jBPM
Issue Type: Bug
Affects Versions: jBPM jPDL 3.2.2
Environment: Jbpm 3.2.2, Tomcat 5.028, MySQL 5.0
Reporter: David Roberts
Assigned To: Tom Baeyens
When you have multiple Tasks on a Node, and each task has a Timer called, for example, "Reminder". Lets say each timer is set to repeat every 24 hours. If you complete one of the Tasks on the node, the Timer called "Reminder" on that task instance ends, but so does every other timer for all other tasks on that node with the name "Reminder". Surely this should not happen?
You could avoid this by naming each Timer differenty, example "Reminder 1", "Reminder 2". But the problem may still happen if you have multiple task instances of the SAME task. Then the name of the Reminders will still be the same, so they will all end when completing one of the task instances.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-1140) Empty <handler> element in <decision> cause org.jbpm.graph.def.DelegationException
by Rafa? ?ukowski (JIRA)
Empty <handler> element in <decision> cause org.jbpm.graph.def.DelegationException
----------------------------------------------------------------------------------
Key: JBPM-1140
URL: http://jira.jboss.com/jira/browse/JBPM-1140
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Rafa? ?ukowski
Assigned To: Tom Baeyens
Priority: Trivial
That is my first issue, forgive me any mistakes and possible redundancy or duplication;)
Using graphical designer I've created process file with empty <handler> :
<decision name="decision1">
<handler></handler>
<transition to="optional" name="to optional"></transition><transition to="first" name="to optional"></transition>
</decision>
And this is not working (org.jbpm.graph.def.DelegationException). After deleting <handler></handler> process is running correctly.
Don't know if this is error in engine or in designer. Maby this kind of decision node is incorrect, and then designer should avoid this situation. My opinion is that engine should ignore empty handlers and go on without errors...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2696) Timers should be read after node-enter actions
by Bernd Ruecker (JIRA)
Timers should be read after node-enter actions
----------------------------------------------
Key: JBPM-2696
URL: https://jira.jboss.org/jira/browse/JBPM-2696
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.8
Reporter: Bernd Ruecker
Priority: Minor
Fix For: jBPM 3.2.x
When parsing the processdefinition, timers are read before all events are read.
This leads to "create-timer" actions being added to the node-enter events BEFORE your own actions. This doesn't make a lot of sense, normally you want your own actions being executed first and the timer created afterwards. From the runtime perspective, it doesn't make any difference (since the timer is started not before the transaciton commits), but with that behavior you could e.g. calculate due dates on the node-enter event (before the time is created).
This is located in the JpdlXmlReader, method "readNode", these two lines:
readNodeTimers(nodeElement, node);
readEvents(nodeElement, node);
See Forum on the discussion how to solve it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBPM-2001) DbLoggingService -> Protected Session Rather than Package Private
by Brad Davis (JIRA)
DbLoggingService -> Protected Session Rather than Package Private
-----------------------------------------------------------------
Key: JBPM-2001
URL: https://jira.jboss.org/jira/browse/JBPM-2001
Project: JBoss jBPM
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: Core Engine
Affects Versions: jBPM 3.2.x
Reporter: Brad Davis
Priority: Minor
Fix For: jBPM 3.2.x
DBLoggingService should have a protected Hibernate session to allow extension. See patch below.
### Eclipse Workspace Patch 1.0
#P jbpm
Index: modules/core/src/main/java/org/jbpm/logging/db/DbLoggingService.java
===================================================================
--- modules/core/src/main/java/org/jbpm/logging/db/DbLoggingService.java (revision 3699)
+++ modules/core/src/main/java/org/jbpm/logging/db/DbLoggingService.java (working copy)
@@ -31,7 +31,7 @@
private static final long serialVersionUID = 1L;
- Session session = null;
+ protected Session session = null;
public DbLoggingService() {
JbpmContext currentJbpmContext = JbpmContext.getCurrentJbpmContext();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years