August 2010 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2658) Process variables of type hibernate-long-id/hibernate-string-id don't work

by Derek Cornelius (JIRA)

Process variables of type hibernate-long-id/hibernate-string-id don't work -------------------------------------------------------------------------- Key: JBPM-2658 URL: https://jira.jboss.org/jira/browse/JBPM-2658 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.2 Reporter: Derek Cornelius This is the same problem as JBPM-2474. The problem is in HibernateIdMatcher. if (sessionFactory!=null) { ClassMetadata classMetadata = sessionFactory.getClassMetadata(value.getClass()); matches = ( (classMetadata!=null) && (classMetadata.getIdentifierType().getClass()==getIdType()) ); } value.getClass() is returning the Javassist proxy class that is not found. It needs to check for "value.getClass().getSuperClass()" if value instance of HibernateProxy. -- 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, 3 months

5
4
0 / 0

[JBoss JIRA] Created: (JBPM-2905) From header is not set on the email

by Jiri Pechanec (JIRA)

>From header is not set on the email ----------------------------------- Key: JBPM-2905 URL: https://jira.jboss.org/browse/JBPM-2905 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 3.2.9 Environment: 3.2.9 in SOA-P 5.0.2 CR3 Reporter: Jiri Pechanec org.jbpm.mail.Mail line 319 serverProperties.setProperty("mail.from", from); should be serverProperties.setProperty("mail.smtp.from", from); otherwise from filed is not set on emails generated by jBPM -- 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, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-2923) Documentation states that dbid can be received using Task interface, but it's not a case

by Alex Makarevitch (JIRA)

Documentation states that dbid can be received using Task interface, but it's not a case ---------------------------------------------------------------------------------------- Key: JBPM-2923 URL: https://jira.jboss.org/browse/JBPM-2923 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.4 Reporter: Alex Makarevitch Fix For: jBPM 4.5 Documentation states that dbid can be received using Task interface, but it's not a case. dbid can be received only by casting to the TaskImpl. That should be fixed either in user guide or in Task interface. -- 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, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPM-2922) Joining of non-concurrent decision paths seems to be broken in 4.4

by Peter Horvath (JIRA)

Joining of non-concurrent decision paths seems to be broken in 4.4 ------------------------------------------------------------------ Key: JBPM-2922 URL: https://jira.jboss.org/browse/JBPM-2922 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Environment: JBPM 4.4; Spring 3 Reporter: Peter Horvath If a join node is used with multiplicity="1" to join two possible outcome paths of a decision node, the join node sets the state of the branch executions to ended which is invalid if the execution path is a part of a concurrent execution: it prevents subsequent join nodes from destroying the incoming executions as they reach that node with "ended" state. This behavior has been changed between JBPM 4.3 and 4.4: process definitions that utilize join nodes with multiplicity attributes to join conditional paths work correctly with JBPM 4.3 but fail with an exception in version 4.4. For me, it seems that the implementation of the join node presumes that the state of branch executions have to be set to ended when a join node is reached, but there can be cases where this is not correct. Let's see the following example: In this case join1 uses multiplicity="1" to wait only for one incoming execution. The execution is expected to pass through this node and reach join2 node where it will be ended: <?xml version="1.0" encoding="UTF-8"?> <process name="ForkJoinTest" xmlns="http://jbpm.org/4.0/jpdl"> <start g="29,95,48,48" name="start1"> <transition g="-23,-25" name="to fork1" to="fork1"/> </start> <fork g="114,95,48,48" name="fork1"> <transition g="138,188:-50,-18" name="to script2" to="script2"/> <transition g="139,72:-68,-18" name="to exclusive1" to="exclusive1"/> </fork> <script expr="Hello world!" g="230,162,92,52" name="script2" var="script2_msg"> <transition g="427,187:-29,4" name="to join2" to="join2"/> </script> <join g="347,51,48,48" multiplicity="1" name="join1"> <transition g="424,76:-7,-17" name="to join2" to="join2"/> </join> <join g="401,97,48,48" name="join2"> <transition g="-21,-21" name="to end1" to="end1"/> </join> <end g="490,97,48,48" name="end1"/> <decision g="162,48,48,48" name="exclusive1"> <transition g="186,30:-12,-19" name="to script1" to="script1"> <condition expr="#{''==''}"/> </transition> <transition name="to join1" to="join1" g="-41,-18"/> </decision> <script expr="Hello world!" g="224,5,92,52" name="script1" var="script1_msg"> <transition g="371,31:-51,-15" name="to join1" to="join1"/> </script> </process> This process definition works correctly with JBPM 4.3 but with JBPM 4.4 it fails with the following exception: Exception in thread "main" org.jbpm.api.JbpmException: execution[ForkJoinTest.10001.to script2.10002] is not active: ended at org.jbpm.pvm.internal.model.ExecutionImpl.checkActive(ExecutionImpl.java:1084) at org.jbpm.pvm.internal.model.ExecutionImpl.take(ExecutionImpl.java:481) at org.jbpm.jpdl.internal.activity.ForkActivity.execute(ForkActivity.java:95) at org.jbpm.jpdl.internal.activity.ForkActivity.execute(ForkActivity.java:46) at org.jbpm.pvm.internal.model.op.ExecuteActivity.perform(ExecuteActivity.java:60) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperationSync(ExecutionImpl.java:672) at org.jbpm.pvm.internal.model.ExecutionImpl.performAtomicOperation(ExecutionImpl.java:632) at org.jbpm.pvm.internal.model.ExecutionImpl.start(ExecutionImpl.java:217) at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:63) at org.jbpm.pvm.internal.cmd.StartProcessInstanceInLatestCmd.execute(StartProcessInstanceInLatestCmd.java:36) at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42) at org.jbpm.pvm.internal.tx.SpringCommandCallback.doInTransaction(SpringCommandCallback.java:45) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130) at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:49) 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:56) at org.jbpm.pvm.internal.svc.ExecutionServiceImpl.startProcessInstanceByKey(ExecutionServiceImpl.java:67) -- 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, 3 months

3
10
0 / 0

[JBoss JIRA] Created: (JBPM-2925) variables in jbpm4_hist_var have no execution id

by HUI-LAN HUNG (JIRA)

variables in jbpm4_hist_var have no execution id ------------------------------------------------ Key: JBPM-2925 URL: https://jira.jboss.org/browse/JBPM-2925 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Environment: OS: ubuntu 10.04 JDK version: 1.6.0_20 jBPM version: jBPM-4.4 Database: postgresql Web Server: apache-tomcat 6.0.29 Reporter: HUI-LAN HUNG I use this code to write variables to jbpm4_hist_var. "executionService.createVariable(task.getExecutionId(),dataMap,true);" when I check database,I found the column 'executionid' always null. I don't know how to write the example testcase to discribe this condition,but I will do my best to add more information about this issue if you need. -- 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, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPM-1992) Logging is missing if JobExecutorThread marks TX as rollbackonly because of max

by Roman Heinz (JIRA)

Logging is missing if JobExecutorThread marks TX as rollbackonly because of max ------------------------------------------------------------------------------- Key: JBPM-1992 URL: https://jira.jboss.org/jira/browse/JBPM-1992 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.3.1 GA Reporter: Roman Heinz If the execution of an action/script/... takes longer than the time configured org.jbpm.job.executor.JobExecutor.maxLockTime, the current TX is marked as rollback-only without any logging. In JobExecutorThread: // if this job is locked too long long totalLockTimeInMillis = System.currentTimeMillis() - job.getLockTime().getTime(); if (totalLockTimeInMillis>maxLockTime) { jbpmContext.setRollbackOnly(); } Logging is missing to inform about the jbpmContext.setRollbackOnly() together with the reason. -- 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, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (JBPM-2873) Nice to have LIKE opertator support for Query objects

by Thomas Victor (JIRA)

Nice to have LIKE opertator support for Query objects ----------------------------------------------------- Key: JBPM-2873 URL: https://jira.jboss.org/browse/JBPM-2873 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Thomas Victor Priority: Optional Process engine has a user supplied keys. In our application we were using certain patters for the keys. For example our keys were like 5-1, 5-2 etc. It will be nice to have a support for querying processes which has key like '5-%'. It will be nice if all the query objects supports like operator. Please see the JIRA issue also https://jira.jboss.org/browse/JBPM-2868 -- 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, 3 months

4
16
0 / 0

[JBoss JIRA] Created: (JBPM-2398) expose full history details through the history api

by Tom Baeyens (JIRA)

expose full history details through the history api --------------------------------------------------- Key: JBPM-2398 URL: https://jira.jboss.org/jira/browse/JBPM-2398 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Tom Baeyens Assignee: Tom Baeyens Fix For: jBPM 4.1 expose the history that is in the database through the 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, 3 months

5
25
0 / 0

[JBoss JIRA] Created: (JBPM-2868) Add a new method 'processDefinitionIdLike' to TaskQuery

by Stephane Malbequi (JIRA)

Add a new method 'processDefinitionIdLike' to TaskQuery ------------------------------------------------------- Key: JBPM-2868 URL: https://jira.jboss.org/browse/JBPM-2868 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.3 Reporter: Stephane Malbequi Priority: Minor Hi, it's not possible to create a task query to find all tasks of all versions of a specific process because TaskQuery append a where clause with a = operator and not a like operator if (processDefinitionId!=null) { appendWhereClause("task.processInstance.processDefinitionId = '"+processDefinitionId+"' ", hql); } May be, it's a good idea to add a new method like 'processDefinitionIdLike' to TaskQuery object in order to append a where clause like that : if (processDefinitionIdLike!=null) { appendWhereClause("task.processInstance.processDefinitionId like '"+processDefinitionIdLike+"' ", hql); } Another method to add should be : 'assigneeIn' in order to append a where clause like that : if (assigneeIn!=null && !assigneeIn.isEmpty()) { appendWhereClause("task.processInstance.assignee in ... } Thanks in advance -- 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, 3 months

4
7
0 / 0

[JBoss JIRA] Created: (JBPM-2908) Creating JbpmConfiguration with a different jbpm.cfg.xml in an action handler causes StackOverflowError

by Toshiya Kobayashi (JIRA)

Creating JbpmConfiguration with a different jbpm.cfg.xml in an action handler causes StackOverflowError ------------------------------------------------------------------------------------------------------- Key: JBPM-2908 URL: https://jira.jboss.org/browse/JBPM-2908 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.9 Environment: SOA-P 4.3.0 CP04 Reporter: Toshiya Kobayashi I tried to switch jbpm.cfg.xml (= create JbpmConfiguration with a different jbpm.cfg.xml) and start a process instance in my action handler. Client: 1. Create a JbpmConfiguration with "jbpm.1.cfg.xml" 2. Create a JbpmContext with the JbpmConfiguration(jbpm.1.cfg.xml) 3. Create and start a process instance Action handler of the process: 4. Create JbpmConfiguration instance with "jbpm.2.cfg.xml" 5. Create a JbpmContext with the JbpmConfiguration(jbpm.2.cfg.xml) 6. jbpmContext.getGraphSession() causes infinite loop and ends up with StackOverFlowError Caused by: java.lang.StackOverflowError at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:210) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65) at org.apache.log4j.Category.callAppenders(Category.java:203) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.logging.impl.Log4jProxy.log(Log4jProxy.java:311) at org.apache.commons.logging.impl.Log4jProxy.info(Log4jProxy.java:273) at org.apache.commons.logging.impl.Log4JLogger.info(Log4JLogger.java:150) at org.hibernate.cfg.Configuration.configure(Configuration.java:1432) at org.jbpm.db.hibernate.HibernateHelper.createConfiguration(HibernateHelper.java:89) at org.jbpm.persistence.db.DbPersistenceServiceFactory.getConfiguration(DbPersistenceServiceFactory.java:69) at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:97) at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94) at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:99) at org.jbpm.persistence.db.DbPersistenceService.getGraphSession(DbPersistenceService.java:330) at org.jbpm.JbpmContext.getGraphSession(JbpmContext.java:618) at org.jbpm.instantiation.ProcessClassLoader.getProcessDefinition(ProcessClassLoader.java:57) at org.jbpm.instantiation.ProcessClassLoader.findResource(ProcessClassLoader.java:63) at java.lang.ClassLoader.getResource(ClassLoader.java:958) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1148) at org.apache.xerces.parsers.SecuritySupport$6.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at org.apache.xerces.parsers.SecuritySupport.getResourceAsStream(Unknown Source) at org.apache.xerces.parsers.ObjectFactory.findJarServiceProvider(Unknown Source) at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source) at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source) at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source) at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.xml.sax.helpers.NewInstance.newInstance(NewInstance.java:51) at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:187) at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:150) at org.dom4j.io.SAXHelper.createXMLReader(SAXHelper.java:83) at org.dom4j.io.SAXReader.createXMLReader(SAXReader.java:894) at org.dom4j.io.SAXReader.getXMLReader(SAXReader.java:715) at org.dom4j.io.SAXReader.read(SAXReader.java:435) at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1490) at org.hibernate.cfg.Configuration.configure(Configuration.java:1434) at org.jbpm.db.hibernate.HibernateHelper.createConfiguration(HibernateHelper.java:89) at org.jbpm.persistence.db.DbPersistenceServiceFactory.getConfiguration(DbPersistenceServiceFactory.java:69) at org.jbpm.persistence.db.DbPersistenceServiceFactory.getSessionFactory(DbPersistenceServiceFactory.java:97) at org.jbpm.persistence.db.DbPersistenceService.getSessionFactory(DbPersistenceService.java:94) at org.jbpm.persistence.db.DbPersistenceService.getSession(DbPersistenceService.java:99) at org.jbpm.persistence.db.DbPersistenceService.getGraphSession(DbPersistenceService.java:330) at org.jbpm.JbpmContext.getGraphSession(JbpmContext.java:618) ... How to reproduce: - Start SOA-P 4.3 CP04 - download and unzip reproducer.zip - copy jbpm.1.cfg.xml and jbpm.2.cfg.xml to <SOA_HOME>/jbossas/server/<config>/deploy/jbpm.esb - cd ProcessDefinitions - modify build.properties - ant deploypar - cd .. - cd ProcessCallWS - modify build.properties - ant deploy - ant run # jbpm.1.cfg.xml and jbpm.2.cfg.xml have same contents as this is a test reproducer Analysis: As the context classloader is ProcessClassLoader in action handler execution, JbpmContext.getGraphSession() -> org.hibernate.cfg.Configuration.configure() let ProcessClassLoader find resources, but ProcessClassLoader invokes JbpmContext.getGraphSession() recursively. Once DbPersistenceServiceFactory builds SessionFactory, the loop won't happen. -- 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, 3 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues August 2010