September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-986) Map Process variables to a well defined schema

by Luca Botti (JIRA)

Map Process variables to a well defined schema ---------------------------------------------- Key: JBPM-986 URL: http://jira.jboss.com/jira/browse/JBPM-986 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: All Reporter: Luca Botti Assigned To: Tom Baeyens Priority: Optional I would find useful map the process variables with a schema similar to the task variables (read/write/mandatory). -- 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

18 years, 8 months

3
2
0 / 0

[JBoss JIRA] Closed: (JBPM-72) required variable declaration

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-72?page=all ] Tom Baeyens closed JBPM-72. --------------------------- Resolution: Won't Fix won't fix till jbpm 4. there we have the opportunity to fix it right. i don't want to introduce an intermediate solution > required variable declaration > ----------------------------- > > Key: JBPM-72 > URL: http://jira.jboss.com/jira/browse/JBPM-72 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Priority: Optional > > we could add support for a configuration that requires all variables to be declared (including the type) before they are used. this creates a bit of 'type safety', although it is only checkable at runtime... > this should be done on the level of the task. maybe tasks should be able to extract data from the process and completion of the task should update the variables in the context. -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-613) Improve variable support

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-613?page=comments#action_12374995 ] Tom Baeyens commented on JBPM-613: ---------------------------------- i meant: intermediate > Improve variable support > ------------------------ > > Key: JBPM-613 > URL: http://jira.jboss.com/jira/browse/JBPM-613 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: J.Enrique Ruiz > Assigned To: Tom Baeyens > Priority: Minor > > Hi, > The JPDL variable element can be used to share info with a new process instance created in a process-state. Sometimes, it is interesting to set the value of a variable in the JPDL, for example: > <process-state name="cms"> > ... > <variable name="documentType" access="read" value="RTF" /> > ... > </process-state> > Currently, we have a ActionHandler that has been defined in the node-enter event. This ActionHandler puts the values in the variable map of the parent process instance, but the new feature can simplify it. > Best regards. -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-613) Improve variable support

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-613?page=all ] Tom Baeyens closed JBPM-613. ---------------------------- Resolution: Won't Fix won't fix till jbpm 4. there we have the opportunity to fix it right. i don't want to introduce an interpediate solution > Improve variable support > ------------------------ > > Key: JBPM-613 > URL: http://jira.jboss.com/jira/browse/JBPM-613 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: J.Enrique Ruiz > Assigned To: Tom Baeyens > Priority: Minor > > Hi, > The JPDL variable element can be used to share info with a new process instance created in a process-state. Sometimes, it is interesting to set the value of a variable in the JPDL, for example: > <process-state name="cms"> > ... > <variable name="documentType" access="read" value="RTF" /> > ... > </process-state> > Currently, we have a ActionHandler that has been defined in the node-enter event. This ActionHandler puts the values in the variable map of the parent process instance, but the new feature can simplify it. > Best regards. -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-672) more examples to explain how to use a non default TaskController.

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-672?page=all ] Tom Baeyens closed JBPM-672. ---------------------------- Resolution: Won't Fix > more examples to explain how to use a non default TaskController. > ----------------------------------------------------------------- > > Key: JBPM-672 > URL: http://jira.jboss.com/jira/browse/JBPM-672 > Project: JBoss jBPM > Issue Type: Task > Components: Documentation > Reporter: Rodrigo Rezende > Assigned To: Tom Baeyens > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The documentation don't explain very well how to use another Action Controllers... Ther is no examples on documentation. -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-378) Broken support for SwimlaneInstance PooledActor reassignment

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-378?page=all ] Tom Baeyens closed JBPM-378. ---------------------------- Assignee: Tom Baeyens (was: Ronald van Kuijk) > Broken support for SwimlaneInstance PooledActor reassignment > ------------------------------------------------------------ > > Key: JBPM-378 > URL: http://jira.jboss.com/jira/browse/JBPM-378 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.0.1 > Environment: JBPM 3.0.1, JBoss 4.0.2, JDK 1.5, Oracle and PostgresSQL > Reporter: Britt Miner > Assigned To: Tom Baeyens > Fix For: jBPM 3.3 > > Attachments: SwimlaneInstPoolAssignmentTest.java, SwimlaneInstPoolAssignmentTests.java > > > The second post of the referenced thread more accurately describes the scope of the problem. > Thanks, > Britt -- 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

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1675) No versionning with upload archive function

by St?phane HUDEC (JIRA)

No versionning with upload archive function ------------------------------------------- Key: JBPORTAL-1675 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1675 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4.1 SP1 Reporter: St?phane HUDEC Assigned To: Sohil Shah Only the new files are commited in CMS with the upload archive function, the files which already exist are not updated. -- 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

18 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPM-738) jboss.com and jboss.org show different download versions

by Ronald van Kuijk (JIRA)

jboss.com and jboss.org show different download versions -------------------------------------------------------- Key: JBPM-738 URL: http://jira.jboss.com/jira/browse/JBPM-738 Project: JBoss jBPM Issue Type: Bug Environment: JBoss sites Reporter: Ronald van Kuijk Assigned To: Tom Baeyens Priority: Critical http://www.jboss.com/products/jbpm/downloads shows jBPM 3.0.4, 3.1.2 and GPD 3.0.11 http://labs.jboss.com/portal/jbossjbpm/download/ shows jBPM 3.1 and GPD 3.0.8 (bpel version is also wrong) Please can somebody fix this. No wonder old errors pop up know and then. -- 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

18 years, 8 months

5
6
0 / 0

[JBoss JIRA] Created: (JBPM-1001) MS SQL server hibernate isolation level issue

by Aleksandar Kostadinov (JIRA)

MS SQL server hibernate isolation level issue --------------------------------------------- Key: JBPM-1001 URL: http://jira.jboss.com/jira/browse/JBPM-1001 Project: JBoss jBPM Issue Type: Bug Reporter: Aleksandar Kostadinov Assigned To: Tom Baeyens When MS SQL server is used hibernate *requires* "hibernate.connection.isolation 4096" in hibernate.properties. Though when this option is set over 200 tests fail. See http://dev45.qa.atl.jboss.com:8585/hudson/job/JBPM.3_mssql2005-msjdbc/2/ and http://dev45.qa.atl.jboss.com:8585/hudson/job/JBPM.3_mssql2005-msjdbc/3/ The first one is with the option and the second one without. You can see the difference. I've marked these builds so hudson will not delete them. If you need this option so you are able to test your changes I'll do. As well you could request an MS SQL server user account for manual testing. FYI I've set some database options so this isolation level is used by default (required for jtds as well as it doesn't support 4096 isolation value). But having the option should not break things as it is not breaking them for hibernate automated builds. -- 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

18 years, 8 months

3
4
0 / 0

[JBoss JIRA] Closed: (JBPM-626) CommandExecutorThread thread safety issues

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-626?page=all ] Tom Baeyens closed JBPM-626. ---------------------------- Resolution: Incomplete Description 2) since 3.2, there are not two separate threads for timers and message. but instead, there is only one job executor. > CommandExecutorThread thread safety issues > ------------------------------------------ > > Key: JBPM-626 > URL: http://jira.jboss.com/jira/browse/JBPM-626 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1, jBPM jPDL 3.2.1, jBPM jPDL 3.2, jBPM 3.1.4, jBPM 3.1.3, jBPM 3.1.2, jBPM 3.1.1 > Environment: Windows XP Pro > Database: DB2/400 v5r3, HSQLDB > Reporter: Mark Shotton > Assigned To: Tom Baeyens > > There appears to be a couple of thread safety problems with the behaviour of the CommandExecutorThread: > (1) Consider the following code: > JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(); > try { > GraphSession graphSession = jbpmContext.getGraphSession(); > > // Find the process definition in the database > ProcessDefinition processDefinition = > graphSession.findLatestProcessDefinition(processDefinitionName); > > // Create an execution of the process definition. > ProcessInstance processInstance = new ProcessInstance(processDefinition); > > // Check that the process instance is in the start state > Token token = processInstance.getRootToken(); > > // Start the process execution > token.signal(); > ? > jbpmContext.save(processInstance); > > } finally { > // Tear down the pojo persistence context. > jbpmContext.close(); > } > If this code is executed while the token is in node ?node 1?, the token.signal() method causes a node-enter event to fire on the next asynchronous node ?node 2? and a message to be stored in the JBPM_MESSAGE table. This message identifies the token as being in ?node 2?. However the node associated with the token in the JBPM_TOKEN table is still in ?node 1? until the jbpmContext.close() method flushes the process instance to the database. > So the JBPM_MESSAGE.NODE for the token is ?node 2? but the JBPM_TOKEN.NODE for the same token is ?node 1?. > This means that on line 53 of org.jbpm.command.ExecuteNodeCommand execute(), an exception is thrown: > public void execute() { > if (! node.equals(token.getNode())) { > throw new JbpmException("couldn't continue execution for '"+token+"', token moved"); > } > and an exception is added to the message so that it is not re-tried. > As a work-around, I modified the org.jbpm.msg.command.CommandExecutorThread handleProcessingException method in a pretty ugly way; I just leave the message in the table to be re-tried if the exception message contains the String ?token moved?: > void handleProcessingException(MessageProcessingException e) { > JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(jbpmContextName); > try { > // get the message session from the context > DbMessageService dbMessageSessionImpl = (DbMessageService) jbpmContext.getServices().getMessageService(); > MessagingSession messageSession = dbMessageSessionImpl.getMessagingSession(); > // get the problematic command message from the exception > Message message = e.message; > // MWS 01/04/06 Workaround for async continuations > // > // Will get this exception if the JBPM_MESSAGE.NODE is not the same as > // the node associated with the JBPM_MESSAGE.TOKEN (i.e. its JBPM_TOKEN.NODE) > // in the JBPM_MESSAGE table (see org.jbpm.command.ExecuteNodeCommand execute()); > // however this can be caused by a token.signal() > // persisting the JBPM_MESSAGE (e.g. from a node-enter on an async node) > // before the token state is persisted by a subsequent call to > // jbpmContext.close(); e.g. > // > // try { > // ... > // token.signal() //Writes to JBPM_MESSAGE if async node entered > // jbpmContext.save(); > // } finally { > // jbpmContext.close //Updates JBPM.TOKEN in DB > // > // i.e. the above is not thread-safe > // > // As a workaround, leave the message to be processed again > // on the following invocation of the CommandExecutorThread > // > if (e.getCause().getMessage() != null) { > if (e.getCause().getMessage().indexOf("token moved")!=-1) { > try { > Thread.sleep(2000); > } catch(InterruptedException ie) { > //Do nothing > } > return; > } > } > > // remove the problematic message from the queue > dbMessageSessionImpl.receiveByIdNoWait(message.getId()); > > message = Message.createCopy(message); > // update the message with the stack trace > StringWriter sw = new StringWriter(); > e.printStackTrace(new PrintWriter(sw)); > message.setException(sw.toString()); > // update the message with the jbpm-error-queue destination > message.setDestination(errorDestination); > > // resend > messageSession.save(message); > } finally { > jbpmContext.close(); > } > } > (2) There also appears to be a problem with the interaction of the SchedulerThread and the CommandExecutorThread. For a node ?node 1? that is marked asynchronous and has a timer that fires on node-enter with an associated action that executes immediately, the ActionHandler on the timer action may progress the token from asynchronous node ?node 1? to node ?node 2? and update the token in the JBPM_TOKEN table. However the update of the JPBM_TOKEN row may occur before the CommandExecutorThread has consumed the message in the JBPM_MESSAGE table that is stored on entry into ?node 1? and details that the token is currently in ?node 1?. > So the JBPM_MESSAGE.NODE for the token is ?node 1? but the JBPM_TOKEN.NODE for the same token is ?node 2?. This means that on line 53 of org.jbpm.command.ExecuteNodeCommand execute(), an exception is thrown (as described in (1)): > public void execute() { > if (! node.equals(token.getNode())) { > throw new JbpmException("couldn't continue execution for '"+token+"', token moved"); > } > If node 2 is also asynchronous, the situation can arise where the same token ID appears in the JBPM_MESSAGE table twice, with each identifying a different node; ?node 1? and ?node 2?. > As a work-around, in the ActionHandler for the timer, I wait for any messages related to the current node to be consumed by the CommandExecutorThread before progressing the token (I make the assumption that the JBPM_MESSAGE table can only contain one message per token): > JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(); > try { > graphSession = jbpmContext.getGraphSession(); > > //Load the processInstance from the database > processInstance = graphSession.loadProcessInstance(getProcessInstanceId()); > ? > MessagingSession messagingSession = jbpmContext.getMessagingSession(); > for (;;) { > java.util.Iterator iterator = messagingSession.getMessageIterator("CMD_EXECUTOR"); > boolean foundToken = false; > while(iterator.hasNext()) { > Message message = (Message) iterator.next(); > if (message.getToken() == token) { > foundToken = true; > } > } > if (foundToken) { > try { > System.out.println("Found message for token: " + token.getId()); > System.out.println("Waiting for CommandExecutorThread to consume message"); > Thread.sleep(500); > } catch (InterruptedException e) { > //Do nothing > } > } else { > break; > } > } > > ? > > //Progress over the 'credit_approved' transition > taskInstance.end("credit_approved"); > jbpmContext.save(processInstance); > } finally { > jbpmContext.close(); > } > Note that I open a new jbpmContext rather than getting this from the ExecutionContext because the code above executes in a new thread spawned by the ActionHandler. However, this work-around occasionally produces the following exception, so I?m obviously doing something wrong (I haven?t investigated this in detail as yet): > Found message for token: 6 > Waiting for CommandExecutorThread to consume message > org.jbpm.persistence.JbpmPersistenceException: couldn't commit hibernate session > at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:171) > at org.jbpm.svc.Services.close(Services.java:211) > at org.jbpm.JbpmContext.close(JbpmContext.java:138) > at com.mdsuk.bpm.webshop.actions.ReceiveCreditReferenceAsyncActionHandler.asyncExecute(ReceiveCreditReferenceAsyncActionHandler.java:103) > at com.mdsuk.bpm.webshop.actions.AsyncActionHandler.run(AsyncActionHandler.java:24) > at java.lang.Thread.run(Unknown Source) > Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#6] > at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1635) > at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2208) > at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118) > at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2374) > at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:84) > at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980) > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:353) -- 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

18 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2007