May 2010 - jbpm-issues - Jboss List Archives

[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

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2444) sub-process-key does not evaluate EL

by Robert Moskal (JIRA)

sub-process-key does not evaluate EL ------------------------------------ Key: JBPM-2444 URL: https://jira.jboss.org/jira/browse/JBPM-2444 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.0 Reporter: Robert Moskal I thought that the sub-process-key (or id) could be an expression the way name could be in the 3.2 product. However, specifying something like this: <sub-process g="228,193,92,52" name="ConcreteWork" sub-process-key="#{SKYLINE_FLOW}"> Always results in the literal value being passed to SubProcessActivity subProcessKey. So, in the above example subProcessKey is "#{SKYLINE_FLOW}" -- 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

5
9
0 / 0

[JBoss JIRA] Created: (JBPM-2808) Document dynamic subprocesses

by Ronald van Kuijk (JIRA)

Document dynamic subprocesses ----------------------------- Key: JBPM-2808 URL: https://jira.jboss.org/jira/browse/JBPM-2808 Project: jBPM Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: jBPM 4.3, jBPM 4.x Reporter: Ronald van Kuijk Priority: Minor Fix For: jBPM 4.4 -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2861) Job retry count configuration is specific to the JobExecutor

by Kevin Conner (JIRA)

Job retry count configuration is specific to the JobExecutor ------------------------------------------------------------ Key: JBPM-2861 URL: https://jira.jboss.org/jira/browse/JBPM-2861 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 3.2.8 Reporter: Kevin Conner As a result this configuration is not visible/possible when alternative executors are used (SOA JCA inflow and jBPM enterprise) -- 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

2
4
0 / 0

[JBoss JIRA] Updated: (JBPM-642) Signaling RootToken on Fork Node

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/browse/JBPM-642?page=com.atlassian.jira.plugin.sys... ] Alejandro Guizar updated JBPM-642: ---------------------------------- Fix Version/s: jBPM 3.2.9 (was: jBPM 3.2.10) > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/browse/JBPM-642 > Project: jBPM > Issue Type: Feature Request > Components: Runtime Engine > Affects Versions: jBPM 3.2.9 > Reporter: Enric Cecilla > Assignee: Alejandro Guizar > Fix For: jBPM 3.2.9 > > Attachments: mylyn-context.zip > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Giving the following processdefinition: > *start->fork->a->join->end > ->b ^ > When RootToken is on Fork node trying to signal again the RootToken actually moves the token to one branch state, then RootToken can be signalled til it is on the Join node. At that moment it can be signalled again and it leaves the Join node. > pi.signal(); > assertEquals( "fork", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "b", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "join", pi.getRootToken().getNode().getName() ); //true > Does it makes any sense being able to signal a RootToken on Fork node which has children on every branch? From my point of view signalling on that condition should throw and Exception. Only child tokens should be allowed to signal since "real" tasks are on child tokens -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-2782) Add JBoss 5.1.0 as supported container

by Alejandro Guizar (JIRA)

Add JBoss 5.1.0 as supported container -------------------------------------- Key: JBPM-2782 URL: https://jira.jboss.org/jira/browse/JBPM-2782 Project: jBPM Issue Type: Task Components: Runtime Engine Reporter: Alejandro Guizar Assignee: Alejandro Guizar Fix For: jBPM 3.2.9 SOA-P 5 is ultimately based off JBoss AS 5.1.0, it would be good to test against this version. -- 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

1
6
0 / 0

[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

3
6
0 / 0

[JBoss JIRA] Created: (JBPM-2852) "CC" support in Mail Nodes & Mail Templates.

by Shishir Choubey (JIRA)

"CC" support in Mail Nodes & Mail Templates. -------------------------------------------- Key: JBPM-2852 URL: https://jira.jboss.org/jira/browse/JBPM-2852 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.2 Environment: Windows Reporter: Shishir Choubey Fix For: jBPM 3.2.x jBPM Mail node does not have "CC" support. In Mail templates, there is tag for CC (<cc>#{ccId}</cc>) but it won't get trigger. So it would be great if somebody can add this feature in Mail node as well as in mail templates. -- 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

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-2864) let RetryIntercept handle HibernateOptimisticLockingFailureException(from spring)

by Huisheng Xu (JIRA)

let RetryIntercept handle HibernateOptimisticLockingFailureException(from spring) --------------------------------------------------------------------------------- Key: JBPM-2864 URL: https://jira.jboss.org/browse/JBPM-2864 Project: jBPM Issue Type: Patch Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.3 Reporter: Huisheng Xu Assignee: Huisheng Xu Priority: Minor Fix For: jBPM 4.4 Spring will wrap StaleObjectException with HibernateOptimisticLockingFailureException. We could use ex.getCause() to get the cause of exception. Later we could let people to configure which Exception should be retried. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPM-2863) correct behaviour of SpringToStandardSynchronization

by Huisheng Xu (JIRA)

correct behaviour of SpringToStandardSynchronization ---------------------------------------------------- Key: JBPM-2863 URL: https://jira.jboss.org/browse/JBPM-2863 Project: jBPM Issue Type: Patch Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.3 Reporter: Huisheng Xu Assignee: Huisheng Xu Priority: Minor Fix For: jBPM 4.4 the status of spring transaction does not equals with jta status. Could not use it directly. Need some convert work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues May 2010