May 2010 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2829) A newline in a decision expression break the scripting engine

by Sebastian Rühl (JIRA)

A newline in a decision expression break the scripting engine ------------------------------------------------------------- Key: JBPM-2829 URL: https://jira.jboss.org/jira/browse/JBPM-2829 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Sebastian Rühl Attachments: jbpm-test-db-NewLineConditionExpressionTest.patch If you put a new line in a decision expression like: <conditionExpression xsi:type="tFormalExpression">${bewertungen>2} </conditionExpression> instead of: <conditionExpression xsi:type="tFormalExpression">${bewertungen>2}</conditionExpression> the scripting engine will fail with a error: org.jbpm.api.JbpmException: Expression '${bewertungen>2} ' did not resolve to a boolean value at org.jbpm.bpmn.model.SequenceflowCondition.evaluate(SequenceflowCondition.java:55) at org.jbpm.bpmn.flownodes.BpmnActivity.findOutgoingSequenceFlow(BpmnActivity.java:134) at org.jbpm.bpmn.flownodes.ExclusiveGatewayActivity.execute(ExclusiveGatewayActivity.java:53) at org.jbpm.bpmn.flownodes.ExclusiveGatewayActivity.execute(ExclusiveGatewayActivity.java:43) at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:657) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:617) at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:418) at org.jbpm.pvm.internal.model.ExecutionImpl.signal(ExecutionImpl.java:404) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:197) at org.jbpm.pvm.internal.model.ExecutionImpl_$$_javassist_32.signal(ExecutionImpl_$$_javassist_32.java) at org.jbpm.pvm.internal.task.TaskImpl.complete(TaskImpl.java:199) at org.jbpm.pvm.internal.cmd.CompleteTaskCmd.execute(CompleteTaskCmd.java:65) at org.jbpm.pvm.internal.cmd.CompleteTaskCmd.execute(CompleteTaskCmd.java:32) at org.jbpm.pvm.internal.cmd.CompositeCmd.execute(CompositeCmd.java:43) at org.jbpm.pvm.internal.cmd.CompositeCmd.execute(CompositeCmd.java:35) at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42) at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54) at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53) at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40) at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55) at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43) at org.jbpm.pvm.internal.svc.TaskServiceImpl.completeTask(TaskServiceImpl.java:105) at org.jbpm.pvm.internal.svc.TaskServiceImpl.completeTask(TaskServiceImpl.java:92) at org.jbpm.bpmn.NewLineConditionExpressionTest.testNormalExecuteDecisionCondition(NewLineConditionExpressionTest.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at org.jbpm.test.BaseJbpmTestCase.runTest(BaseJbpmTestCase.java:87) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) In fact there is a error in jbpm cause the scripting engine will evaluate right but instead of returning true it will return "true" in this case... see appended patch with contains a patch with a test -- 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, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-2871) Cleanly stop JBpm in spring context

by Jaber C. Mourad (JIRA)

Cleanly stop JBpm in spring context ----------------------------------- Key: JBPM-2871 URL: https://jira.jboss.org/browse/JBPM-2871 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.3 Environment: JBpm 4.3, Spring 3.0.2 Reporter: Jaber C. Mourad I using Jbpm integrated to Spring with SpringHelper. When I deploying it in a webapp, the application server cannot shut down the application becaus of DispatcherThread running for the job executor. Is it possible to close ProcessEngine automatically at the end or refresh of spring context to prevent some classloader problems ! -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-2583) IdentityService createGroup creates duplicate groups

by Robert Moskal (JIRA)

IdentityService createGroup creates duplicate groups ---------------------------------------------------- Key: JBPM-2583 URL: https://jira.jboss.org/jira/browse/JBPM-2583 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.1 Environment: JDK 1.6, mysql 5 Reporter: Robert Moskal Repeatedly calling createGroup with the same group name causes very similar records to be entered into the JBPM_ID_GROUP table. They differ only bythe DBID_ field value. Here is an example of what I found in the database. 17 0 another another (null) (null) 18 0 another another (null) (null) 19 0 another another (null) (null) 20 0 another another (null) (null) 21 0 another another (null) (null) Retrievals don't result in duplicates, but this seems like it might cause problems. -- 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, 5 months

4
5
0 / 0

[JBoss JIRA] Created: (JBPM-2693) Identity Service allows creation of duplicate users and groups

by Martin Porter (JIRA)

Identity Service allows creation of duplicate users and groups -------------------------------------------------------------- Key: JBPM-2693 URL: https://jira.jboss.org/jira/browse/JBPM-2693 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.3 Environment: Vista, Oracle 11g, jbpm 4.3 latest trunk Reporter: Martin Porter Priority: Minor Calling identityService.createGroup() or identityService.createUser() with the same details allows creation of duplicates in the database without error. -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-2506) ability to create history entry for variables

by Hauke Rabe (JIRA)

ability to create history entry for variables --------------------------------------------- Key: JBPM-2506 URL: https://jira.jboss.org/jira/browse/JBPM-2506 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: jBPM 4.0 Reporter: Hauke Rabe ScopeInstanceImpl#createVariableObject has the ability to enable history. But there is only a setVariable method wich disables the history. So, add the history flag to user interfaces. -- 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, 5 months

7
36
0 / 0

[JBoss JIRA] Created: (JBPM-1164) Null Pointer Exception is thrown when subprocess is leave event is fired.

by Gurpreet Sahota (JIRA)

Null Pointer Exception is thrown when subprocess is leave event is fired. ------------------------------------------------------------------------- Key: JBPM-1164 URL: http://jira.jboss.com/jira/browse/JBPM-1164 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.2 Environment: Windows XP Pro, Sun JDK 1.5.0_13 Reporter: Gurpreet Sahota Assigned To: Tom Baeyens I have a process flow where process (A) calls a process state that in turn calls subprocess (B). When Subprocess "end" state is signalled then I receive a Null Pointer Exception. Following is stack trace java.lang.NullPointerException at org.jbpm.graph.node.ProcessState.leave(ProcessState.java:204) at org.jbpm.graph.exe.Token.signal(Token.java:195) at org.jbpm.graph.exe.Token.signal(Token.java:140) When debugging, it turns out that "leave" method in ProcessState tries to retrieve subProcessInstance from execution context. This is set to null causing exception. If executionContext.getToken() is used to retrieve the subProcessInstance, then it is not null. -- 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, 5 months

4
5
0 / 0

[JBoss JIRA] Created: (JBPM-2622) fix java static factory method use case

by Tom Baeyens (JIRA)

fix java static factory method use case ---------------------------------------- Key: JBPM-2622 URL: https://jira.jboss.org/jira/browse/JBPM-2622 Project: jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens Assignee: Tom Baeyens Fix For: jBPM 4.3 this doesn't work as expected. <process name="OrderWithRules"> <start> <transition to="isImportant"> <java var="amount" class="java.lang.Integer" method="parseInt"> <arg><object expr="#{amount}" /></arg> </java> </transition> </start> cause is to be found somewhere in JavaBinding, i think if (XmlUtil.attribute(element, "method", true, parse, null)!=null) { UserCodeReference invocationReference = parser.parseUserCodeReference(element, parse); javaActivity.setInvocationReference(invocationReference); ObjectDescriptor objectDescriptor = (ObjectDescriptor) invocationReference.getDescriptor(); javaActivity.setArgDescriptors(objectDescriptor.getArgDescriptors()); objectDescriptor.setArgDescriptors(null); javaActivity.setMethodName(objectDescriptor.getMethodName()); objectDescriptor.setMethodName(null); } by setting the methodName to null in the object descriptor (objectDescriptor.setMethodName(null)), the object descriptor will not see it as a static factory method, but instead will look for the constructor of the class. -- 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, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-2847) DB.verifyClean() in JbpmTestCase.tearDown() fails with DB2

by Joost den Boer (JIRA)

DB.verifyClean() in JbpmTestCase.tearDown() fails with DB2 ---------------------------------------------------------- Key: JBPM-2847 URL: https://jira.jboss.org/jira/browse/JBPM-2847 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.3 Environment: JBPM 4.3 on DB2 v9 database. All tables in JBPMDB schema. Reporter: Joost den Boer At the end of a JbpmTestCase the database is cleaned. This fails for a DB2 database because the default schema is not added to the table name. The created query is "select count(*) as RECORD_COUNT_ from JBPM4_DEPLOYMENT", but this should be "select count(*) as RECORD_COUNT_ from JBPMDB.JBPM4_DEPLOYMENT". The schema name is available in the SessionFactory Settings so should not be to difficult to fix this. -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-2821) Adding a variable converter to jBPM is not intuitive and the documentation is lacking.

by Jochen Mader (JIRA)

Adding a variable converter to jBPM is not intuitive and the documentation is lacking. -------------------------------------------------------------------------------------- Key: JBPM-2821 URL: https://jira.jboss.org/jira/browse/JBPM-2821 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.3 Reporter: Jochen Mader To add a converter to jBPM it's currently required to add it in two places: jbpm.variables.types.xml and jbpm.execution.hbm.xml There are two issues with this: 1) I don't think it's a good approach to be required to edit two files to get the converter enabled. 2) The second file is an internal hibernate mapping file for jBPM and shouldn't be edited by a user for something as simple as adding a converter. At the very least the whole thing should be added to the documentation. Even better would be to enable converters by just adding them to jbpm.variables.types.xml -- 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, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2809) Defer email sending until transaction is commited

by Peter Horvath (JIRA)

Defer email sending until transaction is commited ------------------------------------------------- Key: JBPM-2809 URL: https://jira.jboss.org/jira/browse/JBPM-2809 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: jBPM 4.x Reporter: Peter Horvath Currently emails are sent immediately when they are dispatched from e.g. a mail node or task notification. This can be confusing since the transaction the JBPM execution runs in can be rolled back later. For example a workflow could contain an initial email node which sends a confirmation email to the user who submitted a request ("Your request has been successfully submitted to the workflow system...") - but if the the next node in the workflow throws an exception which rolls back the transaction the submitted request won't be stored in the system. This can be very confusing for the end users. There are similar problems with task notifications as well. I think it would be fairly easy to solve this problem by introducing an optional attribute to the mail node which instructs JBPM to send the email only on transaction commit and modify MailActivity so that it creates a transaction synchronization which sends the email from javax.transaction.Synchronization.afterCompletion(int status) method if the status is COMMITED. -- 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, 5 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues May 2010