[jBPM Users] - [jBPM 4.2] Problem completing a Task
by xalperte
Error when we try to complete a Task and the next activity is also a Task Activity with the "notification" tag set.
Something wrong happens in the MailListener during the process.
Without the "" tag the test runs without errors.
I'm using MySQL (with org.hibernate.dialect.MySQLInnoDBDialect configured).
The process definition is this:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <process description="This is a test process to test: task, swimlines, reminder/notifications, timers." name="Test Websale" xmlns="http://jbpm.org/4.2/jpdl">
| <swimlane candidate-groups="sales" name="Sales Representative"/>
|
| <start g="265,19,48,48" name="Create new web sale order">
| <transition g="14,-11" name="Start web sale" to="Evaluate web order"/>
| </start>
|
| <task form="tasks/form.evaluate.xhtml" g="213,110,153,57" name="Evaluate web order" swimlane="Sales Representative">
| <transition g="14,-10" name="More info needed" to="Fix web order data"/>
| </task>
|
| <task assignee="rex" form="tasks/form.fix.xhtml" g="207,218,169,43" name="Fix web order data">
| <notification />
| <transition g="11,-10" name="End Process" to="To end"/>
| </task>
|
| <end g="270,303,48,48" name="To end" state="completed"/>
|
| </process>
|
And the Test Case used to force the error is this:
| public class SimpleTestCase extends JbpmTestCase {
|
| String deploymentId;
|
| String salesDept;
| String clients;
|
| protected void setUp() throws Exception {
| super.setUp();
|
| // create identities
| salesDept = identityService.createGroup("sales");
| clients = identityService.createGroup("clients");
|
| identityService.createUser("joe", "Joe", "Smoe", "joe@smoe");
| identityService.createMembership("joe", salesDept, "sales-repre");
|
| identityService.createUser("rex", "Rex", "Frez", "rex@frez");
| identityService.createMembership("rex", clients, "client");
|
| // deploy process
| deploymentId = repositoryService.createDeployment()
| .addResourceFromClasspath("test-simple-websale.jpdl.xml")
| .deploy();
|
| // the tearDown of the parent class will dispose the registered deployments
| registerDeployment(deploymentId);
| }
|
| protected void tearDown() throws Exception {
|
| // delete identities
| identityService.deleteUser("joe");
| identityService.deleteUser("rex");
|
| identityService.deleteGroup(salesDept);
| identityService.deleteGroup(clients);
|
| super.tearDown();
| }
|
| public void testWebSaleProcess() throws Throwable {
| // Starting a new instance of the process
| ProcessInstance instance = executionService.startProcessInstanceByKey("Test_Websale");
| String processInstanceId = instance.getId();
|
| // Looking for the group tasks
| List<Task> taskList = taskService.findGroupTasks("joe");
| Task task = taskList.get(0);
|
| // lets assume that joe takes the task
| taskService.takeTask(task.getId(), "joe");
|
| // looking for the new personal task
| taskList = taskService.findPersonalTasks("joe");
| task = taskList.get(0);
|
| // Completing Task.
| taskService.completeTask(task.getId());
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265710#4265710
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265710
16 years, 4 months
[jBPM Users] - Re: takeTask() race condition
by saraswati.santanu
This is a nice feature to have, specially if you need to show something on the UI.
But, this will be very difficult to achieve as well. With FlushMode.Auto, hibernate can do a flush at any point it thinks suitable. So when you call "takeTask" method, hibernate may not complain at all, but at some later point it, when it tries to clear the action queue, then it will complain. So you never know when this exception comes.
One strategy for this might be is to have an exception translator at the DBSession level. But that will be almost as generic as Hibernate exception translator. So whether the Task is taken by somebody or something else happened to the task will be difficult to decide.
But the flip side of this is, a generic exception is caught to give some message which is more context specific then re-thrown - this will also pollute the exception stack trace a bit. As a developer, who is using Jbpm API, I wont like that to happen. I personally would prefer to deal in StaleObjectStateException and inspect what is stale and why. Custom exception on top of that may make finding to root cause a bit difficult for a developer.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265708#4265708
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265708
16 years, 4 months