[JBoss JIRA] Created: (JBPM-2492) GetOutcomes returns an additional Outcome than what is already specified than the
by Shekhar Vemuri (JIRA)
GetOutcomes returns an additional Outcome than what is already specified than the
----------------------------------------------------------------------------------
Key: JBPM-2492
URL: https://jira.jboss.org/jira/browse/JBPM-2492
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.0.CR1
Reporter: Shekhar Vemuri
Fix For: jBPM 4.1
Description is below:
It was decided in a discussion in the forum(referenced in this issue) that we would not add the additional transition to the list of transitions that are available as part of completing a task.
Problem:
Is there a particular reason for why GetOutComes does this?
Code:
Set<String> outcomes = new HashSet<String>();
outcomes.add(Task.STATE_COMPLETED);
.. logic to add other transitions specified in the activity.
When the TaskService.getOutComes(long taskDbId) is called with a task id it returns completed as an entry in the list of Transitions that will eventually be shown to the user.
But this particular transition is not even being modeled in the process_definition.
There are other places in the code, where in if a transition/outcome name is not specified then the transition is assumed to the 'completed' and special handling is done,
Code:
if (Task.STATE_COMPLETED.equals(signalName)) {
if (outgoingTransitions.size()==1) {
transition = outgoingTransitions.get(0);
} else {
transition = activity.getDefaultOutgoingTransition();
}
}
The above snippet is from TaskActivity.
What is the reasoning behind adding this to the transitions that can be taken out of a Task node?
_________________
--
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
[JBoss JIRA] Created: (JBPM-2538) Make a TaskQuery resuable
by Joram Barrez (JIRA)
Make a TaskQuery resuable
-------------------------
Key: JBPM-2538
URL: https://jira.jboss.org/jira/browse/JBPM-2538
Project: jBPM
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.1
Reporter: Joram Barrez
Priority: Minor
Fix For: jBPM 4.3
Queries can't be reused:
TaskQuery openTasksQuery = taskService.createTaskQuery().state(Task.STATE_OPEN);
List<Task> openTasks = openTasksQuery.list();
openTasks = openTasksQuery.list();
The first time list() is called, the HQL query that is produced is fine:
select task from org.jbpm.pvm.internal.task.TaskImpl as task where task.state = 'open'
The second time however, the query is wrong:
select task from org.jbpm.pvm.internal.task.TaskImpl as task and task.state = 'open'
This due to the fact that in AbstractQuery, a boolean is remembered for the where clause:
rotected void appendWhereClause(String whereClause, StringBuilder hql) {
if (isWhereAdded) {
hql.append(" and ");
} else {
isWhereAdded = true;
hql.append("where ");
}
hql.append(whereClause);
}
In the second call, the 'isWhereAdded' boolean is set to true (due to the first call), which leads to not using the where clause and resulting in a wrong query.
--
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
[JBoss JIRA] Created: (JBPM-2608) JobSession.findJobsWithOverdueLockTime returns incorrect list of overdue jobs for LockMonitorThread
by Martin Putz (JIRA)
JobSession.findJobsWithOverdueLockTime returns incorrect list of overdue jobs for LockMonitorThread
---------------------------------------------------------------------------------------------------
Key: JBPM-2608
URL: https://jira.jboss.org/jira/browse/JBPM-2608
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.7, jBPM 3.2.8
Reporter: Martin Putz
Assignee: Alejandro Guizar
Fix For: jBPM 3.2.9
In org.jbpm.job.executor.LockMonitorThread#unlockOverdueJobs(), the list of overdue jobs to be unlocked is queried the following way:
Date threshold = new Date(System.currentTimeMillis() - maxLockTime - lockBufferTime);
List overdueJobs = jbpmContext.getJobSession().findJobsWithOverdueLockTime(threshold);
But the query is incorrect, as it returns all jobs where the lockTime is bigger than the threshold, which means that the job has been locked shorter than (maxLockTime + lockBufferTime):
<query name="JobSession.findJobsWithOverdueLockTime">
<![CDATA[
select job
from org.jbpm.job.Job as job
where job.lockTime > :threshold
]]>
</query>
As a result, the LockMonitorThread will set the lockTime and lockOwner to null, where the same Job instance is also updated by a JobExecutorThread, which will lead to a StaleObjectStateException:
ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (JbpmJobExector:LockMonitorThread@169.1.1.1)
Could not synchronize database state with session
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction
(or unsaved-value mapping was incorrect): [org.jbpm.job.ExecuteActionJob#123]
The 'where' clause in the query needs to be reversed:
Index: modules/core/src/main/resources/org/jbpm/db/hibernate.queries.hbm.xml
===================================================================
--- modules/core/src/main/resources/org/jbpm/db/hibernate.queries.hbm.xml (revision 5825)
+++ modules/core/src/main/resources/org/jbpm/db/hibernate.queries.hbm.xml (working copy)
@@ -385,7 +385,7 @@
<![CDATA[
select job
from org.jbpm.job.Job as job
- where job.lockTime > :threshold
+ where job.lockTime < :threshold
]]>
</query>
--
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
[JBoss JIRA] Created: (JBPM-2639) Task with taskform and timer leads to NPE
by Joram Barrez (JIRA)
Task with taskform and timer leads to NPE
-----------------------------------------
Key: JBPM-2639
URL: https://jira.jboss.org/jira/browse/JBPM-2639
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.2
Reporter: Joram Barrez
Assignee: Joram Barrez
Fix For: jBPM 4.3
Code that throws NPE:
private InputStream loadCSS(String executionId)
{
RepositoryService repoService = processEngine.getRepositoryService();
ExecutionService execService = processEngine.getExecutionService();
ProcessInstance instance = execService.createProcessInstanceQuery()
.processInstanceId(executionId)
.uniqueResult();
ProcessDefinition definition = repoService.createProcessDefinitionQuery()
.processDefinitionId(instance.getProcessDefinitionId()).uniqueResult();
InputStream in = repoService.getResourceAsStream(definition.getDeploymentId(), PROCESSFORMS_CSS);
return in;
}
When a timer is defined on a task, a new execution is created. The procInst query will return null in that case (PARENT != null in HQL).
--
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
[JBoss JIRA] Created: (JBPM-2629) build.xml: install.jbpm.into.jboss ant task does not set database.driver.destination.dir
by Mark Roy (JIRA)
build.xml: install.jbpm.into.jboss ant task does not set database.driver.destination.dir
----------------------------------------------------------------------------------------
Key: JBPM-2629
URL: https://jira.jboss.org/jira/browse/JBPM-2629
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 4.2
Environment: Windows XP, JBoss 5.0GA, Oracle 10g
Reporter: Mark Roy
Priority: Minor
Around line 328 in build.xml, there's an antcall to internal.copy.database.driver, which expects the property database.driver.destination.dir to be set. It appears that instead, the property container.lib.dir is set (this property does not appear to be used anywhere.
Therefore, I believe that
<property name="container.lib.dir" value="${jboss.server.config.dir}/deploy/jbpm/jbpm-service.sar" />
should be
<property name="database.driver.destination.dir" value="${jboss.server.config.dir}/deploy/jbpm/jbpm-service.sar" />
--
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