September 2009 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2393) expand task history to full audit logs

by Tom Baeyens (JIRA)

expand task history to full audit logs -------------------------------------- Key: JBPM-2393 URL: https://jira.jboss.org/jira/browse/JBPM-2393 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 -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2413) productize group activity

by Tom Baeyens (JIRA)

productize group activity ------------------------- Key: JBPM-2413 URL: https://jira.jboss.org/jira/browse/JBPM-2413 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens Assignee: Tom Baeyens Fix For: jBPM 4.1 -- 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, 9 months

5
12
0 / 0

[JBoss JIRA] Created: (JBPM-2263) Multiple timers in node cause EventSource reset

by Asaf Shakarchi (JIRA)

Multiple timers in node cause EventSource reset ----------------------------------------------- Key: JBPM-2263 URL: https://jira.jboss.org/jira/browse/JBPM-2263 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.6.SP1 Reporter: Asaf Shakarchi When having multiple timers in a node, the 2nd timer and all after 'lose' the relationship between the timer->graphElement, thus, timers are being persisted without the relationship with the graphElement, that causes serious problems in job execution time, Here's a deep detail explaination (considering there are two timers in one task node) When entering a node, the 'EVENTTYPE_NODE_ENTER' event gets fired, which causes two 'create timer actions' to be created via CreateTimerAction, one per timer, In GraphElement->fireEvent() there's the following piece of code: ... fireAndPropagateEvent(eventType, executionContext); } finally { executionContext.setEventSource(null); } ... This part seems to clean up the eventSource, but that causes the 2nd timer and above to 'lose' the association to the graphElement(Node ID) the timer was created from, I assume its not taken into consideration that the create timer fires another 'inner' event that causes the eventSource to be reset: CreateTimerAction->createTimer(..) { graphElement.fireEvent(Event.EVENTTYPE_TIMER_CREATE, executionContext); } For now, we commented out the GraphElement->fireEvent->'executionContext.setEventSource(null);' line, but I don't really understand the impact of that, If that line is important, I think it's better to perform the cleanup only in case the fire event is not invoked in an 'inner' fire event call, or find another approach, Thanks. -- 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, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (JBPM-2045) Database maintenance scripts

by Len DiMaggio (JIRA)

Database maintenance scripts ---------------------------- Key: JBPM-2045 URL: https://jira.jboss.org/jira/browse/JBPM-2045 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Productization Affects Versions: jBPM 3.2.5 GA Reporter: Len DiMaggio Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310 -- 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, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPM-2420) fold AddressResolver into IdentitySession

by Tom Baeyens (JIRA)

fold AddressResolver into IdentitySession ----------------------------------------- Key: JBPM-2420 URL: https://jira.jboss.org/jira/browse/JBPM-2420 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens Assignee: Tom Baeyens Fix For: jBPM 4.1 -- 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, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-2499) View ended ProcessInstance missing

by Hauke Rabe (JIRA)

View ended ProcessInstance missing ---------------------------------- Key: JBPM-2499 URL: https://jira.jboss.org/jira/browse/JBPM-2499 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Console Affects Versions: jBPM 4.0 Reporter: Hauke Rabe Ended ProcessInstance are immediately deleted from db. Only history entries left, so the view should be extended. -- 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, 10 months

5
12
0 / 0

[JBoss JIRA] Created: (JBPM-2560) Task definition does not have some properties set from jPDL task element

by Phil Bingley (JIRA)

Task definition does not have some properties set from jPDL task element ------------------------------------------------------------------------ Key: JBPM-2560 URL: https://jira.jboss.org/jira/browse/JBPM-2560 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.1 Environment: jBPM 4.1 Reporter: Phil Bingley The duedate and priority values in a jPDL task definition are not set on the task definition when parsed. This means that the due date is not automatically set when the task is created, nor the priority. -- 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, 10 months

6
28
0 / 0

[JBoss JIRA] Created: (JBPM-2517) Timer with due date set > 24 days in jPDL process definition will cause the timer to be set in the past

by Tobias Groothuyse (JIRA)

Timer with due date set > 24 days in jPDL process definition will cause the timer to be set in the past ------------------------------------------------------------------------------------------------------- Key: JBPM-2517 URL: https://jira.jboss.org/jira/browse/JBPM-2517 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.0 Reporter: Tobias Groothuyse I have a process with <time duedate="5 weeks"/> However when this timer gets instantiated in a running process it's actual duedate which is calculated is in the past. I traced this bug to the following piece of code: TimerImpl.class {code} } else { long millis = duration.getMillis() + 1000*( duration.getSeconds() + 60*( duration.getMinutes() + 60*( duration.getHours() + 24*( duration.getDays() + 7*duration.getWeeks())))); dueDate = new Date(now.getTime() + millis); } {code} Because all the fields from the duration object are of type int, when duration.getDays() is larger then 24 or a weeks larger than 4 for that matter an int overflow will occur and long millis will have a negative value. It is probably best to use the normale calendar operations in all cases to add intervals to the current systime. -- 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, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPM-2047) PersistenceDbServiceTest and PersistenceServiceDbTest are dependent

by Jiri Pechanec (JIRA)

PersistenceDbServiceTest and PersistenceServiceDbTest are dependent ------------------------------------------------------------------- Key: JBPM-2047 URL: https://jira.jboss.org/jira/browse/JBPM-2047 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM-3.2.5.SP1 Reporter: Jiri Pechanec Assignee: Thomas Diesler The tests can fail based on the execution order of these tests. If PersistenceDbServiceTest is executed first then it sets session factory to MockSessionFactory. Unfortunately it seems that the setting is SAME for ALL future newly created JbpmContexts. PersistenceServiceDbTest then tests that the factory is null but it is not assertNull(persistenceServiceFactory.sessionFactory). The same test also tests few more features that ends in calls of unsupported operations on the MockSessionFactory. I am not sure if this is a problem of test - then the sessionFactory should be cleard after test or if it is wrong that the setting is shared for all JBpmContexts. -- 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, 11 months

4
11
0 / 0

[JBoss JIRA] Created: (JBPM-1707) pageflow parsing is slow

by Alejandro Guizar (JIRA)

pageflow parsing is slow ------------------------ Key: JBPM-1707 URL: https://jira.jboss.org/jira/browse/JBPM-1707 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM 3.2.3 Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 7) enterprise-installer-4.3.0.GA-1.ep1.8.jar jdk-1.5.0_16-fcs Reporter: Alejandro Guizar Assignee: Alejandro Guizar Fix For: jBPM 3.3.0 CR1 On a RHEL machine, while deploying a seam based ear, which contains 13 pageflow definitions, the parsing of these 13 pageflow files takes more than 34 minutes (!). The culprit seems to be the usage of the original systemId (http://jboss.com/products/seam/pageflow-2.0.xsd) in the org.jbpm.jdpl.xml.JpdlParser$JpdlEntityResolver class, as this apparently results in slow internet lookups: log.debug("original systemId as input source"); inputSource = new InputSource(systemId); Using a null InputSource: inputSource = new InputSource((InputStream)null); brings the parsing time down to less than 1 second. Of course it would be better to actually pass in a reference to the local pageflow-2.0.xsd file, which is inside the jboss-seam.jar. -- 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, 11 months

4
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues September 2009