March 2009 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2119) Work around the need for an extra column to persist field Join.parentLockMode

by Alejandro Guizar (JIRA)

Work around the need for an extra column to persist field Join.parentLockMode ----------------------------------------------------------------------------- Key: JBPM-2119 URL: https://jira.jboss.org/jira/browse/JBPM-2119 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM-3.2.5.SP4 Reporter: Alejandro Guizar Assignee: Alejandro Guizar Priority: Blocker Fix For: jBPM 3.2.7 GA In JBPM-1755, a new column PARENTLOCKMODE_ was added to table JBPM_NODE for persisting field Join.parentLockMode. Turns out the schema change is a barrier for our customers to upgrade to newer versions. The proposed solution is to provide two different mappings for the Join class, with and without the column. The provided Hibernate configuration will include the mapping without the column by default. Interested parties may inclde the version with the column in their own Hibernate configuration. -- 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

1
6
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-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

[JBoss JIRA] Created: (JBPM-1968) Console integration for jbpm3 doesn't write start instance logs

by Heiko Braun (JIRA)

Console integration for jbpm3 doesn't write start instance logs --------------------------------------------------------------- Key: JBPM-1968 URL: https://jira.jboss.org/jira/browse/JBPM-1968 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: jBPM 3.3.2 GA -- 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-2116) Index names too long for DB2 8.2

by Jiri Pechanec (JIRA)

Index names too long for DB2 8.2 -------------------------------- Key: JBPM-2116 URL: https://jira.jboss.org/jira/browse/JBPM-2116 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM-3.2.5.SP3 Environment: DB2 8.2, JDBC driver 2.10.52, RHEL4 Reporter: Jiri Pechanec Two indices are not created beacuse their names are too long 2009-03-19 06:13:23,025 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] Unsuccessful: create index IDX_PSTATE_SBPRCDEF on JBPM_NODE (SUBPROCESSDEFINITION_) 2009-03-19 06:13:23,025 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] DB2 SQL error: SQLCODE: -107, SQLSTATE: 42622, SQLERRMC: IDX_PSTATE_SBPRCDEF;18 2009-03-19 06:13:23,362 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] Unsuccessful: create index IDX_VARINST_TKVARMP on JBPM_VARIABLEINSTANCE (TOKENVARIABLEMAP_) 2009-03-19 06:13:23,362 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] DB2 SQL error: SQLCODE: -107, SQLSTATE: 42622, SQLERRMC: IDX_VARINST_TKVARMP;18 -- 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-1752) Expression Evaluation in ActionHandler Properties

by Alejandro Guizar (JIRA)

Expression Evaluation in ActionHandler Properties ------------------------------------------------- Key: JBPM-1752 URL: https://jira.jboss.org/jira/browse/JBPM-1752 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Core Engine Reporter: Alejandro Guizar Assignee: Alejandro Guizar Fix For: jBPM 3.3.0 GA The parameters for an ActionHandler should be able to use expressions in it, so you could write <action class="..."> <x>#{someObject.x}</x> </action> This could be done in the FieldInstatiator class (around line 67 we have "setPropertyValue(Class clazz, Object newInstance, String propertyName, Element propertyElement)"), but the execution context is not available there. -- 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

5
10
0 / 0

[JBoss JIRA] Created: (JBPM-2094) Unindexed Foreign Keys cause deadlocks in oracle when trying to kill a worklfow

by Elhanan Maayan (JIRA)

Unindexed Foreign Keys cause deadlocks in oracle when trying to kill a worklfow ------------------------------------------------------------------------------- Key: JBPM-2094 URL: https://jira.jboss.org/jira/browse/JBPM-2094 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.2.0 Environment: aix/red hat linux, websphere 6.1, jvm 1.5 Reporter: Elhanan Maayan attempting to execute deleteProcessInstance api using the follwoing code: LOG.info("Delete process instance " + pi.getId()); try { jbpmContext.getGraphSession().deleteProcessInstance(pi, true, true); LOG.info("finished process instance deleted "); } catch (RuntimeException ex) { LOG.error("problems while delete process", ex); throw ex; } if this code runs in parallal at the same time (like for example from 2 different http requests) then records in jbpm_log table will be deleted, however since jbpm_log has about 13 parent table, and none of them are indexed foreign keys, all 13 will be table locked, causing one process to be deaclocked. after creating more indexes manually this seemed to slove the problem: CREATE INDEX "JBPM_LOG_INDEX1" ON "JBPM_LOG" ("ACTION_") ; CREATE INDEX "JBPM_LOG_INDEX_CHILD" ON "JBPM_LOG" ("CHILD_") ; CREATE INDEX "JBPM_LOG_INDEX_DESTINATIONNODE" ON "JBPM_LOG" ("DESTINATIONNODE_") ; CREATE INDEX "JBPM_LOG_INDEX_NEWBYTEARRAY" ON "JBPM_LOG" ("NEWBYTEARRAY_") ; CREATE INDEX "JBPM_LOG_INDEX_NODE" ON "JBPM_LOG" ("NODE_") ; CREATE INDEX "JBPM_LOG_INDEX_OLDBYTEARRAY" ON "JBPM_LOG" ("OLDBYTEARRAY_") ; CREATE INDEX "JBPM_LOG_INDEX_PARENT" ON "JBPM_LOG" ("PARENT_") ; CREATE INDEX "JBPM_LOG_INDEX_SOURCENODE" ON "JBPM_LOG" ("SOURCENODE_") ; CREATE INDEX "JBPM_LOG_INDEX_SWIMINST" ON "JBPM_LOG" ("SWIMLANEINSTANCE_") ; CREATE INDEX "JBPM_LOG_INDEX_TASKINSTANCE" ON "JBPM_LOG" ("TASKINSTANCE_") ; CREATE INDEX "JBPM_LOG_INDEX_TOKEN" ON "JBPM_LOG" ("TOKEN_") ; CREATE INDEX "JBPM_LOG_INDEX_TRANSITION" ON "JBPM_LOG" ("TRANSITION_") ; CREATE INDEX "JBPM_LOG_INDEX_VARINSTANCE" ON "JBPM_LOG" ("VARIABLEINSTANCE_") ; however i would expect this to be included in the hbm files as this is not a performance issue but actually a causing a failure in our application. CREATE INDEX "JBPM_BYTEARR_INDEX_FILE" ON "JBPM_BYTEARRAY" ("FILEDEFINITION_") ; CREATE INDEX "JBPM_VARINST_INDEX_TINSTANCE" ON "JBPM_VARIABLEINSTANCE" ("TASKINSTANCE_") ; CREATE INDEX "JBPM_VARINST_INDEX_ARR" ON "JBPM_VARIABLEINSTANCE" ("BYTEARRAYVALUE_") ; CREATE INDEX "JBPM_MODINST_INDEX_DF" ON "JBPM_MODULEINSTANCE" ("TASKMGMTDEFINITION_") ; i believe this directly relates to : https://jira.jboss.org/jira/browse/JBPM-931 -- 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
14
0 / 0

[JBoss JIRA] Created: (JBPM-1985) Sort out esb dependencies

by Heiko Braun (JIRA)

Sort out esb dependencies ------------------------- Key: JBPM-1985 URL: https://jira.jboss.org/jira/browse/JBPM-1985 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: jBPM 4.0.0 Alpha1 Reporter: Heiko Braun Assignee: Tom Baeyens Fix For: jBPM 4.0.0.Beta1 Currently jbpm4 depends on jbpm4/dependencies/esb/jbossesb-rosetta/4.4.0.GA/jbossesb-rosetta-4.4.0.GA.jar Dependencies like this should be supplied by the actual project, esb in this case. -- 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-1464) Fix ObjectDescriptor.addTypedInjection(...)

by Guillaume Porcher (JIRA)

Fix ObjectDescriptor.addTypedInjection(...) -------------------------------------------- Key: JBPM-1464 URL: https://jira.jboss.org/jira/browse/JBPM-1464 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: PVM Reporter: Guillaume Porcher Assignee: Tom Baeyens Priority: Critical There is a problem with ObjectDescriptor.addTypedInjection(...). This method uses a EnvironmentTypeRefDescriptor, so this does not work if we use EnvironmentFactory.get(objectName) method (which is the case in org.jbpm.pvm.samples.ex11.AsynchronousContinuationsTest). -- 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
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues March 2009