June 2009 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2317) task forms examples refinement

by Tom Baeyens (JIRA)

task forms examples refinement ------------------------------ Key: JBPM-2317 URL: https://jira.jboss.org/jira/browse/JBPM-2317 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Console, Runtime Engine Reporter: Tom Baeyens Assignee: Heiko Braun Fix For: jBPM 4.0 Let's discuss this wish list, see what can be done by when and spin off jiras as appropriate. Currently taskform is a separate example. I think it's much better if we remove the separate taskform example and instead decorate 2 of the existing task processes with task forms. Are tasks without a taskform completable in the console ? (executing all examples by using the console only) Heiko, can you look at the start task concept in jBPM 3 ? I think we need something similar in jBPM 4. The basic idea is that a process can have a task form associated with a process for starting a new process instance. Such forms are unrelated to tasks and anyone can use such form to start a new process instance for a selected process definition. I think the example users that are loaded in the demo.setup should match with the task assignments in the example processes. That way our users can easily switch to the assigned user(s) in the console to see populated task lists. It will be easiest to update the sql script to match the users/groups in the examples, as the examples are also documented. -- 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

15 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-2351) Incorporate task forms in process definition

by Joram Barrez (JIRA)

Incorporate task forms in process definition -------------------------------------------- Key: JBPM-2351 URL: https://jira.jboss.org/jira/browse/JBPM-2351 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Joram Barrez Priority: Minor Fix For: jBPM 4.1 Defining the relation between a task and a task form should be possible in the process definition: <task name="myTask" form="dir/in/business/archive/myTask.form ... -- 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

15 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-2301) process start forms

by Tom Baeyens (JIRA)

process start forms ------------------- Key: JBPM-2301 URL: https://jira.jboss.org/jira/browse/JBPM-2301 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Console Reporter: Tom Baeyens Assignee: Heiko Braun Fix For: jBPM 4.1 in jbpm 3 wee have a mechanism where starting of process could be done with a form. something similar should be introduced in the current console / forms support. -- 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

15 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBPM-2210) Add support for AS 5.1.x

by Heiko Braun (JIRA)

Add support for AS 5.1.x ------------------------ Key: JBPM-2210 URL: https://jira.jboss.org/jira/browse/JBPM-2210 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Heiko Braun Assignee: Tom Baeyens Fix For: jBPM 4.0.0.CR1 As 5.1 is already CR1. We should have on the QA matrix. Hence the installer needs to support 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

15 years, 5 months

3
7
0 / 0

[JBoss JIRA] Created: (JBPM-2062) remove version specification in module pom dependencies

by Tom Baeyens (JIRA)

remove version specification in module pom dependencies ------------------------------------------------------- Key: JBPM-2062 URL: https://jira.jboss.org/jira/browse/JBPM-2062 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens Assignee: Tom Baeyens currently, the dependencies on jbpm modules have the version specified when they are used. this is also done in the parent pom so that is actually not necessary. the fix is that the version specification in the module poms should be removed. -- 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

15 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBPM-2040) Inconsistent behaviour depending on the ordering of events (fork+end state+join)

by Thomas Diesler (JIRA)

Inconsistent behaviour depending on the ordering of events (fork+end state+join) -------------------------------------------------------------------------------- Key: JBPM-2040 URL: https://jira.jboss.org/jira/browse/JBPM-2040 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.2.3 Reporter: Mauro Molinari Assignee: Thomas Diesler Given the following process definition: <?xml version="1.0" encoding="UTF-8"?> <process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="Complex"> <description> Complex description </description> <start-state name="start-state1"> <transition to="task-node1"></transition> </start-state> <task-node name="task-node3"> <task name="Task3_1"> <assignment actor-id="1"></assignment> </task> <transition to="end-state1"></transition> </task-node> <node name="node1"> <transition to="task-node3"></transition> </node> <join name="join1"> <transition to="node1"></transition> </join> <fork name="fork1"> <transition to="task-node2"></transition> <transition to="node2" name="to node2"></transition> <transition to="state1" name="to state1"></transition> </fork> <task-node name="task-node2"> <task name="Task2_1"> <assignment actor-id="1"></assignment> </task> <task name="Task2_2"> <assignment actor-id="1"></assignment> </task> <transition to="join1"></transition> </task-node> <task-node name="task-node1"> <task name="Task1_1"> <assignment actor-id="1"></assignment> </task> <transition to="fork1"></transition> </task-node> <node name="node2"> <transition to="end-state2"></transition> </node> <state name="state1"> <transition to="end-state2"></transition> </state> <end-state name="end-state1"></end-state> <end-state name="end-state2"></end-state> </process-definition> Try to do this: - create a process instance and start it - a Task1_1 instance is created: end it - the root token halts at the fork and three children tokens are created 1) the first causes the creation of a Task2_1 instance and of a Task2_2 instance 2) the second halts at the state1 state 3) the third dies at the end-state2 state Now, there are two cases: CASE A) - signal the second token: it then goes on and dies at end-state2 state - end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join - now, the root token is restored and goes through node1 and task-node3 nodes, causing the creation of a Task3_1 instance This is what I would expect! CASE B) - end Task2_1 and Task2_2 instances so that the first token goes on and reaches the join - signal the second token: it then goes on and dies at end-state2 state - now, the root token is ended, halting the process instance! This is not the expected behaviour, as I would expect that the root token is restored because now all the sibling tokens of those that have reached the join node are ended, so the parent token (= the root token) should be restored and should continue to node1 and subsequent nodes. Moreover, I would not expect that the behaviour is different depending on the ordering of the actions "signal the state1 token" and "signal the task-node2 token". My suspect is this: in case B) the join node is not "triggered" anymore after Task2_1 and Task2_2 are ended, so it can't restore the parent node. Moreover, when the second children token is signalled, it reaches end-state2: jBPM then realizes that all of the sibling tokens are also ended, so it wrongly decides that the parent token should also be ended. -- 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

15 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-2347) Transitive dependency pointing to snapshot repository

by Johan Kumps (JIRA)

Transitive dependency pointing to snapshot repository ----------------------------------------------------- Key: JBPM-2347 URL: https://jira.jboss.org/jira/browse/JBPM-2347 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.0.CR1 Reporter: Johan Kumps Priority: Minor When adding the Jbpm dependancy to a pom.xml like this : <dependency> <groupId>org.jbpm.jbpm4</groupId> <artifactId>jbpm-pvm</artifactId> <version>4.0.CR1</version> </dependency> a transitive dependency is downloaded from the snapshot Jboss repository. It would be better to use the latest release in the default Jboss repository. Work around : <dependency> <groupId>org.jbpm.jbpm4</groupId> <artifactId>jbpm-pvm</artifactId> <version>4.0.CR1</version> <exclusions> <exclusion> <groupId>org.jboss.identity.idm</groupId> <artifactId>idm-core</artifactId> </exclusion> <exclusion> <groupId>org.jboss.identity.idm</groupId> <artifactId>idm-hibernate</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.jboss.identity.idm</groupId> <artifactId>idm-core</artifactId> <version>1.0.0.Alpha8</version> </dependency> <dependency> <groupId>org.jboss.identity.idm</groupId> <artifactId>idm-hibernate</artifactId> <version>1.0.0.Alpha8</version> </dependency> -- 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

15 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-2297) Fork activities don't save child executions

by Alexis Seigneurin (JIRA)

Fork activities don't save child executions ------------------------------------------- Key: JBPM-2297 URL: https://jira.jboss.org/jira/browse/JBPM-2297 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.0.0.Beta2 Reporter: Alexis Seigneurin When you create a fork activity, child executions are not saved in the session. The consequence is that, at some point, an execution with ID 0 is searched in the database: Exception in thread "main" org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [org.jbpm.jpdl.internal.model.JpdlExecution#0] at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:375) at org.hibernate.proxy.AbstractLazyInitializer.checkTargetState(AbstractLazyInitializer.java:79) at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:68) at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111) at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:140) at org.jbpm.jpdl.internal.model.JpdlExecution$$EnhancerByCGLIB$$9a4d98d.createTask(<generated>) at org.jbpm.jpdl.internal.activity.TaskActivity.execute(TaskActivity.java:49) at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:57) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:589) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:562) at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:444) at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:448) at org.jbpm.jpdl.internal.activity.ForkActivity.execute(ForkActivity.java:61) at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:57) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:589) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:562) at org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:201) at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:63) at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:39) at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42) at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54) at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:54) at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55) at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:72) To fix the issue, in the ForkActivity class, the childExecution instances which are created must be saved. I attached a patch (though I guess there is another way to perform the save by using commands). -- 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

15 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-2343) completeTask with submitting variables

by Bernd Ruecker (JIRA)

completeTask with submitting variables -------------------------------------- Key: JBPM-2343 URL: https://jira.jboss.org/jira/browse/JBPM-2343 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Bernd Ruecker Priority: Minor Fix For: jBPM 4.x These two methods should be invoked in one method: taskService.setVariable(task.getDbid(), "problem", "Out of stock"); taskService.completeTask(task.getDbid()); Maybe there should be a similar task where you set process variables as weill? -- 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

15 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPM-2014) Provide equivalent activities as in jBPM3

by Heiko Braun (JIRA)

Provide equivalent activities as in jBPM3 ----------------------------------------- Key: JBPM-2014 URL: https://jira.jboss.org/jira/browse/JBPM-2014 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Core Engine Reporter: Heiko Braun Assignee: Heiko Braun jBPM4 should have at least the same functional scope then jBPM3. -- 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

15 years, 5 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues June 2009