[JBoss JIRA] Created: (JBPM-2760) Fix generics specification in ExecutionService interface
by M M (JIRA)
Fix generics specification in ExecutionService interface
--------------------------------------------------------
Key: JBPM-2760
URL: https://jira.jboss.org/jira/browse/JBPM-2760
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.1, jBPM 4.2, jBPM 4.3
Reporter: M M
Currently, some of the ExecutionService interface methods have parameters whose type is specified like
Map<String, Object> variables
However, when attempting to call these with methods with, say, an object of type Map<String,String>, the java compiler will not accept the object without some casting. To fix this, please change the interface to use the wildcard feature of Java 5 generics. This has already been done on other methods. The above would change to:
Map<String, ?> variables
Please also fix the same issue on TaskService (methods setVariables and completeTask). This change would be backwardly-compatible.
--
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, 7 months
[JBoss JIRA] Created: (JBPM-2677) Migration of process instances fails when there are no process instances
by Edgar Vonk (JIRA)
Migration of process instances fails when there are no process instances
------------------------------------------------------------------------
Key: JBPM-2677
URL: https://jira.jboss.org/jira/browse/JBPM-2677
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.2
Reporter: Edgar Vonk
When the process definition includes a 'migrate-instances' entry like:
{code}
<migrate-instances versions="*"/>
{code}
The migration of process instances fails when there are no process instances in the jBPM database:
{quote}
EXCEPTION ###########################################
16:15:36,793 INF | [DefaultCommandService] exception while executing command org.jbpm.pvm.internal.cmd.DeployCmd@1a550
f9
java.lang.IndexOutOfBoundsException: fromIndex = -1
at java.util.SubList.<init>(AbstractList.java:600)
at java.util.RandomAccessSubList.<init>(AbstractList.java:758)
at java.util.AbstractList.subList(AbstractList.java:468)
at org.jbpm.pvm.internal.migration.InstanceMigrator.getProcessesToMigrate(InstanceMigrator.java:104)
at org.jbpm.pvm.internal.migration.InstanceMigrator.getProcessInstancesToMigrate(InstanceMigrator.java:84)
[..]
{quote}
This issue is caused by the following code in the InstanceMigrator class:
{code}
private static List<ProcessDefinition> getProcessesToMigrate(String processDefinitionName, MigrationDescriptor migrationDescriptor) {
RepositorySession repositorySession = EnvironmentImpl.getFromCurrent(RepositorySession.class);
List<ProcessDefinition> processDefinitions = repositorySession
.createProcessDefinitionQuery()
.processDefinitionName(processDefinitionName)
.orderAsc(ProcessDefinitionQuery.PROPERTY_VERSION)
.list();
int startIndex = calculateStartIndex(processDefinitions.size() - 1, migrationDescriptor);
int endIndex = calculateEndIndex(processDefinitions.size() - 1, migrationDescriptor);
if (startIndex > endIndex) startIndex = endIndex;
return processDefinitions.subList(startIndex, endIndex);
}
{code}
No check is done to see if the list of processes (processDefinitions) is not empty.
This issue causes our unit tests to fail since our unit tests start with an empty jBPM database.
--
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, 7 months
[JBoss JIRA] Created: (JBPM-2838) Mark jboss-j2ee dependency as scope=provided
by M M (JIRA)
Mark jboss-j2ee dependency as scope=provided
--------------------------------------------
Key: JBPM-2838
URL: https://jira.jboss.org/jira/browse/JBPM-2838
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: M M
Please mark the dependency on jboss as <scope>provided</scope>
Here is the relevent section of the jbpm-api pom:
<dependencies>
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-j2ee</artifactId>
</dependency>
</dependencies>
This is not an issue of determining minimal dependency (it certainly needs this dependency), but rather, decoupling the jbpm api from any specific J2EE vendor implementation or version. Users of the jbpm api will then not have a transitive dependency on a specific version of jboss.
The current workaround is to exclude this dependency when depending on the jbpm api.
--
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, 7 months
[JBoss JIRA] Created: (JBPM-2537) A triggered timer does not end the task which is left
by Alexis Seigneurin (JIRA)
A triggered timer does not end the task which is left
-----------------------------------------------------
Key: JBPM-2537
URL: https://jira.jboss.org/jira/browse/JBPM-2537
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.0, jBPM 4.1
Reporter: Alexis Seigneurin
In my process definition, "task1" has a transition with a due date. When this timer is triggered by the job executor, the transition takes the process to "task2" but "task1" still looks active. For instance, when I run a "task query", instead of only finding "task2", both "task1" and "task2" are found.
Here is my process definition:
<?xml version="1.0" encoding="UTF-8"?>
<process name="test1" xmlns="http://jbpm.org/4.0/jpdl">
<start g="-9,192,48,48" name="start1">
<transition g="-44,-18" name="to task3" to="task3" />
</start>
<end g="490,192,48,48" name="end1" />
<task g="272,189,92,52" name="task1">
<transition g="-42,-18" name="to end1" to="end1" />
<transition g="-45,-18" name="to java1" to="reminder">
<timer duedate="10 seconds" />
</transition>
</task>
<java class="fr.idm.SimpleReminder" g="272,316,92,52" method="remind" name="reminder">
<transition to="task2" />
</java>
<end g="626,319,48,48" name="end2" />
<task g="454,316,92,52" name="task2">
<transition g="-42,-18" name="to end2" to="end2" />
</task>
<task g="113,189,92,52" name="task3">
<transition g="-44,-18" to="task1" name="to end1" />
</task>
</process>
For testing purpose, I introduced "task3" before "task1". It is not listed by the task query, which makes me think that, once "task1" is left, it should no longer be active.
This looks like https://jira.jboss.org/jira/browse/JBPM-967 but the suggested solution does not seem applicable to JBPM 4.x.
I will attached the whole source code.
--
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, 7 months
[JBoss JIRA] Created: (JBPM-2828) ContextInstance.deleteVariable() does not delete the variable from the database
by Martin Putz (JIRA)
ContextInstance.deleteVariable() does not delete the variable from the database
-------------------------------------------------------------------------------
Key: JBPM-2828
URL: https://jira.jboss.org/jira/browse/JBPM-2828
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: jBPM 3.2.8
Reporter: Martin Putz
Assignee: Martin Putz
A call to ContextInstance.deleteVariable(name) does not actually delete the variable from the database. Instead, in the VariableContainer.deleteVariable() method, only the references to the process execution are removed, and a new log entry is added. This can lead to orphaned records in the database.
The applied fix removes the variable instances from the database *if the logging service is disabled*. With the logging service enabled, the variable cannot be deleted right away, as the new VariableDeleteLog instance holds a reference to the variable. These records will eventually be deleted upon process instance deletion.
--
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, 7 months
[JBoss JIRA] Created: (JBPM-1162) Problem with exception handling within the Decision nodes
by Jon Folland (JIRA)
Problem with exception handling within the Decision nodes
---------------------------------------------------------
Key: JBPM-1162
URL: http://jira.jboss.com/jira/browse/JBPM-1162
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Environment: Vaio laptop running Windows Vista, Java 1.5, JBPM 3.2.2
Reporter: Jon Folland
Assigned To: Tom Baeyens
I believe there may be a bug in the Decision class where exception handling is concerned which causes this failure:
If the line: String transitionName = decisionHandler.decide(executionContext); ...
...in the method public void execute(ExecutionContext executionContext)
throws an exception, which is caught here in the same method:
raiseException(exception, executionContext);
We miss the block:
if (transition==null) {
transition = getDefaultLeavingTransition();
log.debug("decision didn't select transition, taking default "+transition);
}
So when executionContext.leaveNode(transition); is called at the bottom, there wil be no transition set.
I believe we need to check for a tranistion==null condition regardless of whether an excpetion has been handled. Otherwise you will never be able to handle an exception in a Decision without another unhandled exception being thrown (which kind of defeits the point :-)
--
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, 7 months