January 2009 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Resolved: (JBPM-1223) Add "and" to duration language in timers

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1223?page=com.atlassian.jira.plug... ] Tom Baeyens resolved JBPM-1223. ------------------------------- Fix Version/s: (was: jBPM 4.0.0 Alpha2) Resolution: Rejected first goal is to cover the jbpm 4 functionality. adding this feature is nice to have, but not crucial. > Add "and" to duration language in timers > ---------------------------------------- > > Key: JBPM-1223 > URL: https://jira.jboss.org/jira/browse/JBPM-1223 > Project: JBoss jBPM > Issue Type: Task > Components: PVM > Environment: All > Reporter: Jim Rigsbee > Assignee: Tom Baeyens > Priority: Minor > > Currently the PDL allows for duration expressions of the type <quantity> {business} <unit>, e.g. 5 business hours or 5 days. Please expand this to allow the word "and" between multiple nodes. The time should be aggregated as milliseconds. Some examples, > 5 business days and 2 hours, > 1 month and 25 days and 2 minutes > Tom's suggestion is that if business appears anywhere in the string that the entire duration is considered to be in "business time". -- 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

17 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1757) StaleObjectStateException and Rollback in Join- Node

by Rainer Buss (JIRA)

StaleObjectStateException and Rollback in Join- Node ----------------------------------------------------- Key: JBPM-1757 URL: https://jira.jboss.org/jira/browse/JBPM-1757 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: jPDL 3 Affects Versions: jBPM 3.2.3 Environment: Mac Osx 10.5.5, JBoss AS 4.2.3 GA, jbpm-jpdl-3.2.3-suite, Oracle 10g Express Server 1.1 Reporter: Rainer Buss Executing a test process inside JBoss 4.2.3 using jbpm-enterprise.ear throws StaleObjectStateException in Join- node. The process consists of two nodes with async = true between fork and join. Please see process- defintion and action- handler in the referenced forum entry. The rollback causes one node action to be executed twice. Modifications of the distributed ear: I customized the ear by changing the property 'hibernate.dialect' to 'Oracle9iDialect' in hibernate.cfg.xml. As transaction factory I tried JTATransactionFactory as well as CMTTransactionFactory, without change of behaviour in this case. File jbpm.cfg.xml I kept unchanged. (Setting the node attributes to async=false the instance is processed without error) I will attach a log with and without sql- tracing. In my opinion the issue is not dependent on using oracle, because I had the same effect with the preinstalled hsqldb. -- 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

17 years, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (JBPM-1898) Leave-Superstate Event Executes Incorrectly

by Brad Davis (JIRA)

Leave-Superstate Event Executes Incorrectly ------------------------------------------- Key: JBPM-1898 URL: https://jira.jboss.org/jira/browse/JBPM-1898 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM 3.3.0 GA Reporter: Brad Davis Priority: Minor When there are nested superstates, events are processed incorrectly. Example: superstate w/ leave-superstate event { nested superstate w/leave-superstate event { ... } } When the nested superstate is left, but the execution remains in the parent superstate, both the parent and nested superstate's events for leave-superstate will execute. The correct functionality would be that only the event for the superstate being left should be fired. -- 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

17 years, 3 months

4
3
0 / 0

[JBoss JIRA] Created: (JBPM-1874) org.jbpm.jpdl.xml.JpdlXmlReader doesn't use org/jbpm/graph/action/action.types.xml to create Create(Cancel)TimerAction

by oleg babul (JIRA)

org.jbpm.jpdl.xml.JpdlXmlReader doesn't use org/jbpm/graph/action/action.types.xml to create Create(Cancel)TimerAction ----------------------------------------------------------------------------------------------------------------------- Key: JBPM-1874 URL: https://jira.jboss.org/jira/browse/JBPM-1874 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.3.1 GA Reporter: oleg babul It's impossible to customize CreateTimerAction, because org.jbpm.jpdl.xml.JpdlXmlReader uses new CreateTimerAction() in the org.jbpm.jpdl.xml.JpdlXmlReader.readNodeTimer(Element, Node) instead of creating action based on the org/jbpm/graph/action/action.types.xml (the same for CancelTimerAction) -- 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

17 years, 3 months

4
3
0 / 0

[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

17 years, 3 months

4
5
0 / 0

[JBoss JIRA] Resolved: (JBPM-1016) ProcessState 'leave' method always returns default transition

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1016?page=com.atlassian.jira.plug... ] Tom Baeyens resolved JBPM-1016. ------------------------------- Fix Version/s: (was: jBPM 3.3.2 GA ) Resolution: Rejected this new feature will only be added in jbpm 4 > ProcessState 'leave' method always returns default transition > -------------------------------------------------------------- > > Key: JBPM-1016 > URL: https://jira.jboss.org/jira/browse/JBPM-1016 > Project: JBoss jBPM > Issue Type: Patch > Components: Core Engine > Affects Versions: jBPM 3.2.0 > Reporter: Randy Gullett > Assignee: Alejandro Guizar > > The leave method for ProcessStates currently automatically takes the default transition despite taking a transition as a parameter. Can it be modified so that it leaves by the transition passed in (if it isn't null) like you'd expect it to? I want to be able to short-circuit my subprocesses in certain scenarios. See the method as it's currently coded below. > public void leave(ExecutionContext executionContext, Transition transition) { > ProcessInstance subProcessInstance = executionContext.getSubProcessInstance(); > Token superProcessToken = subProcessInstance.getSuperProcessToken(); > // feed the readable variableInstances > if ((variableAccesses != null) && (!variableAccesses.isEmpty())) { > ContextInstance superContextInstance = executionContext.getContextInstance(); > ContextInstance subContextInstance = subProcessInstance.getContextInstance(); > // loop over all the variable accesses > Iterator iter = variableAccesses.iterator(); > while (iter.hasNext()) { > VariableAccess variableAccess = (VariableAccess) iter.next(); > // if this variable access is writable > if (variableAccess.isWritable()) { > // the variable is copied from the sub process mapped name > // to the super process variable name > String mappedName = variableAccess.getMappedName(); > Object value = subContextInstance.getVariable(mappedName); > String variableName = variableAccess.getVariableName(); > log.debug("copying sub process var '"+mappedName+"' to super process var '"+variableName+"': "+value); > if (value!=null) { > superContextInstance.setVariable(variableName, value, superProcessToken); > } > } > } > } > // fire the subprocess ended event > fireEvent(Event.EVENTTYPE_SUBPROCESS_END, executionContext); > // remove the subprocess reference > superProcessToken.setSubProcessInstance(null); > > // We replaced the normal log generation of super.leave() by creating the log here > // and overriding the addNodeLog method with an empty version > superProcessToken.addLog(new ProcessStateLog(this, superProcessToken.getNodeEnter(), new Date(), subProcessInstance)); > // call the subProcessEndAction > [b]super.leave(executionContext, getDefaultLeavingTransition());[/b] } > The bold line could be replaced by something like: > if(transition != null) { > super.leave(executionContext, transition); > } else { > super.leave(executionContext, getDefaultLeavingTransition()); -- 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

17 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1889) setVariable on token level works illogical

by Tom Eugelink (JIRA)

setVariable on token level works illogical ------------------------------------------ Key: JBPM-1889 URL: https://jira.jboss.org/jira/browse/JBPM-1889 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.2.3 Reporter: Tom Eugelink If you do a setVariable(<name>, <value>, <token>) on a token, but the variable does not exist, the token parameter is ignored and the setVariable is done on the root token. This is confusing. On the other hand createVariable(<name>, <value>, <token>) on a token works as one would expect setVariable to: a variable is created and updated with this call. The documentation only mentions setVariable, but the Javadoc does describe the setVariable behavior, so it is intentional. I still would suggest to make a more natural behavior: - createVariable truly only creates, if the variable exists it should thrown an exception. - setVariable, creates and/or updates the variable I'm fully aware that breaking the API's behavior is unwanted, which is why the following may come in handy. The only way AFAIK to set a variable starting at a token is by executing the code below: token.getProcessInstance().getContextInstance().setVariable("var","value", token); It would be more logical to be able to do it like this: token.setVariable("var","value"); So I would suggest adding a setVariable method to Token that behaves like the createVariable of ContextInstance. -- 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

17 years, 3 months

3
3
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

17 years, 3 months

3
4
0 / 0

[JBoss JIRA] Commented: (JBPM-1082) process start interval calculation is not correct and limited to special databases

by Tom Baeyens (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-1082?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1082: ----------------------------------- bernd, do i understand this issue correctly ? in order for you to do simulation, you need to query the diff between 2 timestamp properties in the jbpm DB. and you didn't find an HQL way of getting that information. first, i do acknowledge that this is a normal feature request. it would be a normal next enhancement of jBPM 3. but the strategy in jbpm 3 for such queries has always been that users are on their own for such matters. so i don't see a problem if users have to go for native queries like you indicated. in jbpm 4 i would like to extend the core engine functionality to include portable querying of this kind of information. did the native queries solve the problem for you ? > process start interval calculation is not correct and limited to special databases > ---------------------------------------------------------------------------------- > > Key: JBPM-1082 > URL: https://jira.jboss.org/jira/browse/JBPM-1082 > Project: JBoss jBPM > Issue Type: Bug > Components: Simulation > Affects Versions: jBPM 3.2.2 > Reporter: Bernd Ruecker > > See Forum. > The date interval calculation is right now only tested with mySQL. And even there I got wrong results... > By the way, this may be somehow to http://jira.jboss.com/jira/browse/JBPM-1080 -- 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

17 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1872) set up db matrix job for jbpm 4

by Tom Baeyens (JIRA)

set up db matrix job for jbpm 4 ------------------------------- Key: JBPM-1872 URL: https://jira.jboss.org/jira/browse/JBPM-1872 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens Assignee: Tom Baeyens Fix For: jBPM 4.0.0 Alpha1 At a minimal, MySql should be in there, but oracle, postgres and other tier 1 DBs from the soa platform would be nice. -- 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

17 years, 3 months

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues January 2009