August 2008 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-1110) Having issues when I execute a second instance of a workflow that contain sub-process's in a Oracle database

by Eric Paquette (JIRA)

Having issues when I execute a second instance of a workflow that contain sub-process's in a Oracle database ------------------------------------------------------------------------------------------------------------ Key: JBPM-1110 URL: http://jira.jboss.com/jira/browse/JBPM-1110 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.1 Environment: Oracle DB using Alfreso with Hibernate Reporter: Eric Paquette Assigned To: Tom Baeyens Priority: Critical I'm having issues when I execute a second instance of a workflow that contain sub-process's in a Oracle database: [20/12/07 14:25:33:757 EST] 00000029 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl initialize FFDC0009I: FFDC opened incident stream file C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\ffdc\server1_6500650_07.12.20_14.25.33_0.txt [20/12/07 14:25:33:978 EST] 00000029 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl resetIncidentStream FFDC0010I: FFDC closed incident stream file C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\ffdc\server1_6500650_07.12.20_14.25.33_0.txt [20/12/07 14:25:34:018 EST] 00000029 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl open FFDC0009I: FFDC opened incident stream file C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\ffdc\server1_6500650_07.12.20_14.25.34_0.txt [20/12/07 14:25:34:859 EST] 00000029 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl resetIncidentStream FFDC0010I: FFDC closed incident stream file C:\Program Files\IBM\SDP70\runtimes\base_v61\profiles\AppSrv01\logs\ffdc\server1_6500650_07.12.20_14.25.34_0.txt [20/12/07 14:25:35:249 EST] 00000029 SystemOut O 14:25:34,929 User:admin ERROR [ui.common.Utils] A system error happened during the operation: Transaction didn't commit: Could not execute JDBC batch update; nested exception is org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update javax.transaction.RollbackException: Transaction didn't commit: Could not execute JDBC batch update; nested exception is org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update at org.alfresco.util.transaction.SpringAwareUserTransaction.commit(SpringAwareUserTransaction.java:430) at org.alfresco.web.bean.workflow.ManageTaskDialog.transition(ManageTaskDialog.java:396) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:132) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:61) at javax.faces.component.UICommand.broadcast(UICommand.java:109) at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:97) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:171) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:907) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145) at org.alfresco.web.app.servlet.AuthenticationFilter.doFilter(AuthenticationFilter.java:81) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130) at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:701) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:646) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:475) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:93) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213) at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510) Caused by: org.springframework.dao.DataIntegrityViolationException: Could not execute JDBC batch update; nested exception is org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:622) at org.springframework.orm.hibernate3.HibernateTransactionManager.convertHibernateAccessException(HibernateTransactionManager.java:714) at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:583) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:662) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632) at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:314) at org.alfresco.util.transaction.SpringAwareUserTransaction.commit(SpringAwareUserTransaction.java:420) ... 40 more Caused by: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:218) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2174) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2610) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:52) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:575) ... 44 more Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (NHPOLS.SYS_C007328) violated at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:459) at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:4368) at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecuteBatch(WSJdbcPreparedStatement.java:808) at com.ibm.ws.rsadapter.jdbc.WSJdbcStatement.executeBatch(WSJdbcStatement.java:612) at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:4 at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242) ... 59 more -- 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

16 years

4
5
0 / 0

[JBoss JIRA] Created: (JBPM-1129) On signalling a subprocess, the workflow does not stop at the start state of the subprocess even if a task is present in start state of subprocess

by Debnath Mukherjee (JIRA)

On signalling a subprocess, the workflow does not stop at the start state of the subprocess even if a task is present in start state of subprocess -------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBPM-1129 URL: http://jira.jboss.com/jira/browse/JBPM-1129 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2, jBPM 3.1.4 Environment: Windows XP, JBPM 3.1.4. Most likely also present in 3.2.2. Reporter: Debnath Mukherjee Assigned To: Tom Baeyens Test case and setup details are available in the JBPM forum post. If the first state of a subprocess contains a task, there is no opportunity to create the task, as, on signalling the process state, the workflow does not stop at the first state but goes to the first task (defined in a task-node) in the subprocess. -- 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

16 years

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-1376) Bug in JPDL 3.2.3 when using a configuration file not named 'jbpm.cfg.xml' (worked in 3.2.2)

by Joram Barrez (JIRA)

Bug in JPDL 3.2.3 when using a configuration file not named 'jbpm.cfg.xml' (worked in 3.2.2) -------------------------------------------------------------------------------------------- Key: JBPM-1376 URL: http://jira.jboss.com/jira/browse/JBPM-1376 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: jPDL 3 Affects Versions: jPDL 3.2.3 Environment: Windows XP, Eclipse 3.4, 0 JDK 1.6.0.05_b13 Reporter: Joram Barrez Priority: Critical Bug discovered when porting app from 3.2.2 to 3.2.3. Application uses a config file which is not named 'jbpm.cfg.xml'. See forum reference for more information and test class. Test class works for JPDL 3.2.2, but not for 3.2.3. Adding jbpm.cf.xml to the class path resolves the issue. However, by default jbpm should not fail to start and use the standard config which is in the distribution. -- 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

16 years

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-1465) NullPointerException on transaction.rollback() in DbPersistenceService

by Martin Putz (JIRA)

NullPointerException on transaction.rollback() in DbPersistenceService ---------------------------------------------------------------------- Key: JBPM-1465 URL: https://jira.jboss.org/jira/browse/JBPM-1465 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jPDL 3.2.3, SOA 4.2 CP02 Reporter: Martin Putz Assignee: Alejandro Guizar We are having NullPointerException from DbPersistenceService when Hibernate throws Exception on close() method. The line is transaction.rollback(); in rollback() method. My two cents is this code should be embraced with "if ( isTransactionEnabled && (transaction != null) )" statement, because we are using external JDBC Connection provider, and the transaction reference never be set. All calls to the rollback() method in DbPersistenceService are already preceded by a check for if ( (isTransactionEnabled) && (transaction!=null) ) { except this one after an exception has happened during the Hibernate session.flush call: Exception flushException = flushSession(); if (flushException!=null) { rollback(); // missing check if there is a transaction closeSession(); closeConnection(); throw new JbpmPersistenceException("hibernate flush failed", flushException); } -- 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

16 years

2
4
0 / 0

[JBoss JIRA] Created: (JBPM-1429) Custom FunctionMapper implementation is not picked up in org.jbpm.mail.Mail

by Martin Putz (JIRA)

Custom FunctionMapper implementation is not picked up in org.jbpm.mail.Mail --------------------------------------------------------------------------- Key: JBPM-1429 URL: https://jira.jboss.org/jira/browse/JBPM-1429 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jPDL 3.2.3 Reporter: Martin Putz Assignee: Alejandro Guizar Fix For: JBossBPM-3.3.0 I have created a custom implementation of the FunctionMapper, which provides a custom function I want to use in an email template. Now, after I add the reference to this FunctionMapper to jbpm.cfg.xml: <bean name="jbpm.function.mapper" class="org.jbpm.jpdl.el.impl.DateFormatFunctionMapper" singleton="true" /> it will get picked up, but unfortunately, the default Mail class does not use it because it always sets the FunctionMapper to null in the evaluate method (last parameter): String evaluate(String expression) { //... return (String) JbpmExpressionEvaluator.evaluate(expression, executionContext, variableResolver, null); this should be : return (String) JbpmExpressionEvaluator.evaluate(expression, executionContext, variableResolver, JbpmExpressionEvaluator.getUsedFunctionMapper()); -- 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

16 years

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-1694) move UserTransaction lookup to persistence service factory

by Alejandro Guizar (JIRA)

move UserTransaction lookup to persistence service factory ---------------------------------------------------------- Key: JBPM-1694 URL: https://jira.jboss.org/jira/browse/JBPM-1694 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: jPDL 3.2.3 Reporter: Alejandro Guizar Fix For: JBossBPM-3.3.0.GA In jBPM 3.2.3 and earlier, the UserTransaction object is retrieved from JNDI every time a JTA persistence service is opened and no transaction is in progress. This works fine; however, the UserTransaction might as well be retrieved only once and cached in the JTA persistence service factory. -- 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

16 years

1
4
0 / 0

[JBoss JIRA] Created: (JBPM-1248) examples do not have a javac source/target defined

by Alejandro Guizar (JIRA)

examples do not have a javac source/target defined -------------------------------------------------- Key: JBPM-1248 URL: http://jira.jboss.com/jira/browse/JBPM-1248 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: jBPM jPDL 3.2.3 Reporter: Alejandro Guizar Fix For: jBPM jPDL 3.2.4 The javac tasks in example.base.build.xml have neither the source nor target attributes set. This causes the example classes to be compiled under whatever jdk version the compiler is using. In the case of the published 3.2.3 distro, the compiler used was jdk 6. Hence the examples can only be run under jre 6, otherwise an UnsupportedClassVersionError is thrown. -- 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

16 years

1
3
0 / 0

[JBoss JIRA] Created: (JBPM-1098) businesscalendar is unaware of leapyears

by Ronald van Kuijk (JIRA)

businesscalendar is unaware of leapyears ---------------------------------------- Key: JBPM-1098 URL: http://jira.jboss.com/jira/browse/JBPM-1098 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Environment: Windows 2000, jdk 1.5.2_12 Reporter: Ronald van Kuijk Assigned To: Tom Baeyens Priority: Minor businesscalendar of 65 years is 65/4 = 16 days short ( based on 1971). -- 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

16 years

3
12
0 / 0

[JBoss JIRA] Created: (JBPM-1106) GetProcessInstancesCommand should use Query.setTimestamp instead of Query.setDate.

by Alexey Kostylev (JIRA)

GetProcessInstancesCommand should use Query.setTimestamp instead of Query.setDate. ---------------------------------------------------------------------------------- Key: JBPM-1106 URL: http://jira.jboss.com/jira/browse/JBPM-1106 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Alexey Kostylev Assigned To: Tom Baeyens In current impementation we cannot filter process instances using time. -- 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

16 years

3
5
0 / 0

[JBoss JIRA] Created: (JBPM-1119) Timers using EjbSchedulerService are not persisted across JBoss restarts

by Aner Perez (JIRA)

Timers using EjbSchedulerService are not persisted across JBoss restarts ------------------------------------------------------------------------ Key: JBPM-1119 URL: http://jira.jboss.com/jira/browse/JBPM-1119 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.1 Environment: JBoss 4.0.5 Reporter: Aner Perez Assigned To: Tom Baeyens Timers created using the EjbSchedulerService do not fire if JBoss is restarted after the timer is set. The reason is that although the JBPM timer row still exists in the database, there is no corresponding EJB timer to kick off the JBPM timer action. EJB timers are supposed to persist across server restarts but there is a catch. JBPM uses an EJB with a "local" interface to dispatch the JBPM timers. JBoss (as of 4.0.2) has decided to make the jndi name of EJBs with local interfaces have a unique name by appending an '@' sign and a hashcode to the EJB name. This hash code is different every time the server is restarted. When the EJB timers are reloaded after a restart, the EJB that is supposed to receive the timer doesn't exist anymore because it now has a different name (different hashcode). This causes the timers to be deactivated and they do not fire at the appointed time. See http://wiki.jboss.org/wiki/Wiki.jsp?page=WhyDoesTheLocalNameContainARando... for an explanation of the EJB name issue for EJBs with a local interface. We need a local-jndi-name parameter added to the TimerServiceBean so we can always locate it under the same name and the timers will work as expected. adding the following to jboss.xml takes care of this issue: <session> <ejb-name>TimerServiceBean</ejb-name> <local-jndi-name>TimerServiceBean</local-jndi-name> </session> -- 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

16 years

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues August 2008