March 2008 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-1154) jBPM example "action" - wrong package name referenced in JUnit tests

by Len DiMaggio (JIRA)

jBPM example "action" - wrong package name referenced in JUnit tests -------------------------------------------------------------------- Key: JBPM-1154 URL: http://jira.jboss.com/jira/browse/JBPM-1154 Project: JBoss jBPM Issue Type: Bug Components: Training Affects Versions: jBPM jPDL 3.2.2 Reporter: Len DiMaggio Assigned To: Tom Baeyens Priority: Minor Project issue for http://jira.jboss.com/jira/browse/SOA-481 -- 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

15 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-1084) NPE in VariableAccess with Oracle persistence

by Tom Baeyens (JIRA)

NPE in VariableAccess with Oracle persistence --------------------------------------------- Key: JBPM-1084 URL: http://jira.jboss.com/jira/browse/JBPM-1084 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Tom Baeyens Assigned To: Tom Baeyens Oracle treats empty strings as null values. So the Access component value object is removed after storage and retrieval fronm the db in case the Access value field is an empty string. As a solution, an empty string is replaced with a space in case an Access object is created with an empty string. -- 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

15 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-1137) Leap Year Date Calculations

by Alejandro Guizar (JIRA)

Leap Year Date Calculations --------------------------- Key: JBPM-1137 URL: http://jira.jboss.com/jira/browse/JBPM-1137 Project: JBoss jBPM Issue Type: Support Patch Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Alejandro Guizar Assigned To: Tom Baeyens Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There might be issues around the end of Feb. Durations that are not expressed in months or years work correctly under the current model. Consider the following expression. endDate = new Date(startDate.getTime() + interval); If startDate is February 28, 2008 and interval is 1 day, then endDate will be February 29, 2008. Every day has the same duration even on leap years. The presentation layer is responsible of converting the milliseconds in a Date to a suitable representation in the calendar system. The Java APIs are all aware of leap years, so this is covered as well. The situation is different for months and years. If the interval above was 1 year, then endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate has shifted backwards one day. To fix this, our Duration class has to preserve the original unit of time instead of converting to milliseconds up front. Then we can do the following. startCalendar = Calendar.getInstance(); startCalendar.setTime(startDate); startCalendar.add(unit, interval); endDate = startCalendar.getTime(); -- 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 month

6
25
0 / 0

[JBoss JIRA] Created: (JBPM-1146) Leap Year Date Calculations (v3.1.4)

by Alejandro Guizar (JIRA)

Leap Year Date Calculations (v3.1.4) ------------------------------------ Key: JBPM-1146 URL: http://jira.jboss.com/jira/browse/JBPM-1146 Project: JBoss jBPM Issue Type: Support Patch Components: Core Engine Affects Versions: jBPM 3.1.4 Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Based on JBPM-1098 there is concern over date calculations in in jBPM 3.1 and 3.2. There might be issues around the end of Feb. The problem is characterized as follows. Under the current model, durations that are not expressed in months or years work correctly. Consider the following expression. endDate = new Date(startDate.getTime() + interval); If startDate is February 28, 2008 and interval is 1 day, then endDate will be February 29, 2008. Every day has the same duration even on leap years. The presentation layer is responsible of converting the milliseconds in a Date to a suitable representation in the calendar system. The Java APIs are all aware of leap years, so this is covered as well. The situation is different for months and years. If the interval above was 1 year, then endDate would be February 27, 2009. Because of the extra day in 2008, the expected endDate has shifted backwards one day. To fix this, the Duration class has to preserve the original unit of time instead of converting to milliseconds up front. Calculation of endDate can then be delegated to java.util.Calendar as follows. startCalendar = Calendar.getInstance(); startCalendar.setTime(startDate); startCalendar.add(unit, interval); endDate = startCalendar.getTime(); -- 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 month

7
21
0 / 0

[JBoss JIRA] Assigned: (JBPM-826) Incorrect action exception handling

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-826?page=all ] Alejandro Guizar reassigned JBPM-826: ------------------------------------- Assignee: Alejandro Guizar (was: Tom Baeyens) > Incorrect action exception handling > ----------------------------------- > > Key: JBPM-826 > URL: http://jira.jboss.com/jira/browse/JBPM-826 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1.3 > Environment: Eclipse + Tomcat + JDK 6.0 > Reporter: Pedro Silva > Assigned To: Alejandro Guizar > Priority: Critical > > If an action in a process definition throws an exception it doesn't correctly reach the client class, e.g. the class doing the signalling. > Imagine that you have a process definition that in one of the task as an action that opens a file for reading. If the file cannot be found there will be an exception. Te exception is thrown and when it reaches the class, where the code for signalling is, you can't see the exception message. If you try to do, in the catch block, System.err.println(e.getMessage()) the result is null! However if you print System.err.println(e.getCause().getMessage()) the result is the file not found exception. > This is worst in the case when you caught the exception in the action delegated class and you throw your own exception by explicitly doing: throw new MyException("Some error"); and the message still is null. > In the case where the exception occurs in another class than the one of the action (if the execute code of the action invokes another class), even the code System.err.println(e.getCause().getMessage()) outputs null. > The documentattion clearly states in 9.7 Exception Handling: > "...Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. ..." -- 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 month

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-826) Incorrect action exception handling

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-826?page=comments#action_12405620 ] Alejandro Guizar commented on JBPM-826: --------------------------------------- Checked exceptions cannot be thrown directly to the client unless wrapped in an unchecked exception. Runtime exceptions /could/ be thrown directly; however, even in this case it is useful to have a wrapper exception that immediately tells that the original exception occurred in user code as opposed to jBPM code. In both cases DelegationException is the solution. The DelegationException message could be set to the original exception's. Apart from that, I do not see how the exception handling is incorrect. > Incorrect action exception handling > ----------------------------------- > > Key: JBPM-826 > URL: http://jira.jboss.com/jira/browse/JBPM-826 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1.3 > Environment: Eclipse + Tomcat + JDK 6.0 > Reporter: Pedro Silva > Assigned To: Tom Baeyens > Priority: Critical > > If an action in a process definition throws an exception it doesn't correctly reach the client class, e.g. the class doing the signalling. > Imagine that you have a process definition that in one of the task as an action that opens a file for reading. If the file cannot be found there will be an exception. Te exception is thrown and when it reaches the class, where the code for signalling is, you can't see the exception message. If you try to do, in the catch block, System.err.println(e.getMessage()) the result is null! However if you print System.err.println(e.getCause().getMessage()) the result is the file not found exception. > This is worst in the case when you caught the exception in the action delegated class and you throw your own exception by explicitly doing: throw new MyException("Some error"); and the message still is null. > In the case where the exception occurs in another class than the one of the action (if the execute code of the action invokes another class), even the code System.err.println(e.getCause().getMessage()) outputs null. > The documentattion clearly states in 9.7 Exception Handling: > "...Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. ..." -- 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 month

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-787) centralize cache configurations

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-787?page=comments#action_12403604 ] Tom Baeyens commented on JBPM-787: ---------------------------------- committed so this will be in the next release. it might be another couple of weeks till we get that release out, though. > centralize cache configurations > ------------------------------- > > Key: JBPM-787 > URL: http://jira.jboss.com/jira/browse/JBPM-787 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2.3 > > Attachments: hibernate.cfg.xml, jbpm.3-jpdl-hbm-cluster-patch.zip, jbpm.3-jpdl_3_2_2-hbm-cluster.patch.zip, jpwh-replicated-cache-excerpt.pdf > > > for easier update of the cache configurations. see attachment -- 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 month

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1085) Join of new process instance fails in Oracle

by Tom Baeyens (JIRA)

Join of new process instance fails in Oracle -------------------------------------------- Key: JBPM-1085 URL: http://jira.jboss.com/jira/browse/JBPM-1085 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.2 Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM jPDL 3.2.3, jBPM 3.2.2 SOA 1 If in one transaction you create a new process instance and reach a join, you'll get a invalid StaleObjectStateException. The cause is that in case of oracle, hibernate will not insert the record in the database before the forced version increment in the join will be executed. That results in 0 rows updated and hence a StaleStateObjectException. The fix applied is that we added a flush before the forced version update in the join -- 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 month

1
3
0 / 0

jbpm PageFlow

by Ankit Kakkar

Hi, I posted few queries in the jboss jbpm forum. Pls refer to http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137706 for that. See if you guys can help me out. Ankit Kakkar | Senior Associate Engg. | GlobalLogic Inc. The Global Product Development Leader USA | INDIA | UKRAINE | CHINA B-34/1, Sector 59, Noida 201301 (U.P) Office: +91-120-406-2000 x 4397 | Mobile +91-995-879-3545 Fax: +91-120-258-5721 www.globallogic.com <http://www.globallogic.com/> InfoWorld Award Winner for Agile Innovation <http://www.globallogic.com/Media/pressReleaseDetail.asp?press/65> Disclaimer: http://www.globallogic.com/email_disclaimer.txt <https://webmail.globallogic.com/exchweb/bin/redir.asp?URL=http://www.gl oballogic.com/email_disclaimer.txt>

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (JBPM-1072) Concurrent JobExecutors can process the same job in parallel

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-1072?page=all ] Alejandro Guizar resolved JBPM-1072. ------------------------------------ Resolution: Done The cause of multiple performances of the same job has been identified and the solution proposed so this issue is resolved. An alternate version of MultiJobExecutorTest that relies on passive waiting instead of active polling was committed, although not included in the test suite. > Concurrent JobExecutors can process the same job in parallel > ------------------------------------------------------------ > > Key: JBPM-1072 > URL: http://jira.jboss.com/jira/browse/JBPM-1072 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM jPDL 3.2.2 > Environment: Linux 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux > MySQL 5.0.22 > Reporter: Jiri Pechanec > Assigned To: Alejandro Guizar > Attachments: expl.tar.gz > > > Attached is a simple test case that > 1) Deploys process definition with two nodes > 2) Starts 20 executor threads > 2) Starts the process instance that will asynchronously execute action on the second node > 4) The second node writes a record to the database > The test case needs to be executed multiple times to see the incorrect behaviour. > This is an example of run output > Isol 8 > Action 1 > Success 0 > Failure 0 > Action 2 > Action 2 1 > Action 2 > Action 2 1 > Action 2 > Action 2 1 > Action 2 > Action 2 1 > Action 2 > Action 2 1 > Action 2 > Action 2 1 > Action 2 > Action 2 > Action 2 1 > Action 2 1 > Action 2 > Action 2 1 > Explanation of the outcome > 9 job executors successfully executed the node action (same job) including database operation. All database operations were comitted (9 new records were created) -- 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 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues March 2008