[JBoss JIRA] Created: (JBPM-2657) No override of convenience methods in SpringConfiguration
by Walter Seymore (JIRA)
No override of convenience methods in SpringConfiguration
---------------------------------------------------------
Key: JBPM-2657
URL: https://jira.jboss.org/jira/browse/JBPM-2657
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.2
Environment: Spring
Reporter: Walter Seymore
Priority: Minor
Fix For: jBPM 4.3
Attachments: ProcessEngineImpl.patch
When using spring to define some components, (specifically the ones exposed in the convenience methods provided by ProcessEngine e.g. getTaskService(), getExecutionService() etc.), trying to retrieve these from the process engine does not go through the overridden get(Class c) method.
Either the SpringConfiguration should also override these methods, or even better, the ProcessEngineImpl should use the get(Class c) method for resolving them instead of going straight to the wire context.
--
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-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