October 2010 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2830) (BPMN) In Latest source jbpm uses the name instead of the id for processes

by Sebastian Rühl (JIRA)

(BPMN) In Latest source jbpm uses the name instead of the id for processes -------------------------------------------------------------------------- Key: JBPM-2830 URL: https://jira.jboss.org/jira/browse/JBPM-2830 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Sebastian Rühl In Latest source jbpm uses the name instead of the id for processes... In my opinion this is the wrong behaviour as the name of a process will be converted to a id. So if you want to start a process via: executionService.startProcessInstanceByKey("process4711") it will throw a exception. Example Process for this: <process id="process4711" name="Could be a very long description and is not used to IDENTIFY"> -- 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, 2 months

4
11
0 / 0

[JBoss JIRA] Created: (JBPM-1776) org.jbpm.calendar.BusinessCalendar.add(Date, Duration) delivers unexpected results when business amounts are subtracted

by JÃÂÃÂ¼rgen Lampe (JIRA)

org.jbpm.calendar.BusinessCalendar.add(Date, Duration) delivers unexpected results when business amounts are subtracted ----------------------------------------------------------------------------------------------------------------------- Key: JBPM-1776 URL: https://jira.jboss.org/jira/browse/JBPM-1776 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: API Affects Versions: jBPM 3.2.3 Environment: java.version 1.5.0_13 java.vm.version 1.5.0_13-b05 os.name Windows XP os.version 5.1 Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 1.7.0-b21 (Sun Microsystems Inc.) Implementation-Title: jBPM Core Library Implementation-Version: 3.2.3 (date:18-Jun-2008 00:51) Implementation-URL: http://www.jboss.org/ Implementation-Vendor: JBoss Inc. Implementation-Vendor-Id: http://www.jboss.org/ Reporter: JÃÂÃÂ¼rgen Lampe When subtracting business time amounts from a date, the result is after the date and not - as one would expect - before this date. Examples: Sat Nov 01 00:00:00 CET 2008 + 2 business days -> Tue Nov 04 17:00:00 CET 2008 - OK Sat Nov 01 00:00:00 CET 2008 - 2 business days -> Sun Nov 02 18:00:00 CET 2008 - unexpected Sat Nov 01 00:00:00 CET 2008 + 2 business hours -> Mon Nov 03 11:00:00 CET 2008 - OK Sat Nov 01 00:00:00 CET 2008 -2 business hours -> Mon Nov 03 07:00:00 CET 2008 - unexpected Data was created by use of small test program: Date date=new SimpleDateFormat("dd.MM.yyyy").parse("01.11.2008"); String[] durStrs= {"+ 2 business days", "- 2 business days", "+ 2 business hours", "-2 business hours"}; BusinessCalendar calendar= new BusinessCalendar(); for (String durStr: durStrs) { Duration duration= new Duration(durStr); Date d= calendar.add(date, duration); System.out.println(" "+date+" "+durStr+" -> "+d); } -- 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, 2 months

9
16
0 / 0

[JBoss JIRA] Created: (JBPM-2927) ease hibernate package

by Huisheng Xu (JIRA)

ease hibernate package ---------------------- Key: JBPM-2927 URL: https://jira.jboss.org/browse/JBPM-2927 Project: jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Huisheng Xu Assignee: Huisheng Xu Fix For: jBPM 4.5 In order to support other data persistence strategies, e.g. jdbc, jpa, ibatis, it is better to gether hibernate package to DbSessionImpl and *QueryImpl. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
8
0 / 0

[JBoss JIRA] Created: (JBPM-2954) SharedProcessClassLoaderFactory: problematic class loader caching for non-deployed process definitions

by Mauro Molinari (JIRA)

SharedProcessClassLoaderFactory: problematic class loader caching for non-deployed process definitions ------------------------------------------------------------------------------------------------------ Key: JBPM-2954 URL: https://jira.jboss.org/browse/JBPM-2954 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.7 Reporter: Mauro Molinari When you are working with non-deployed process definitions and you want to get a reference to their own process class loader, if these two process definitions share the same name the class loader of the first is returned for the second too by org.jbpm.instantiation.SharedProcessClassLoaderFactory. This is because org.jbpm.instantiation.SharedProcessClassLoaderFactory.getProcessClassLoader(ProcessDefinition) determines if the same class loader had been requested before by using: - the id of the process definition, if available (i.e.: for the deployed process definitions) - the hashCode of the process definition otherwise (i.e.: for non-deployed process definitions) The problem is that, if the process definition is not deployed, the resulting hashCode is a function of just its name. So, the two process definitions mentioned above are treated like they were an only one, because they share the same name. I think a more correct approach is to use System.identityHashCode() for non-deployed process definitions, because in that case it's reasonable to consider a process definition better identified by its instance rather than by just some of its characteristics. This is the approach I followed for my resolutions of the problem I described in my comments to bug JBPM-2428 and it works well. Maybe a more correct and full solution could be to calculate the hashCode of a non-deployed ProcessDefinition taking into account also its FileDefinition, not only its name and version. In this way the result of org.jbpm.graph.def.ProcessDefinition.hashCode() would be consistent for all of its uses. However, it may be hard to implement an efficient hashCode for FileDefinition... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-2960) maven repository

by Sandro Roeder (JIRA)

maven repository ---------------- Key: JBPM-2960 URL: https://jira.jboss.org/browse/JBPM-2960 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Environment: maven 2 Reporter: Sandro Roeder Hello Jboss-Team, i migrate from Version 4.3 to 4.4 but i can't find the 4.4 version in the maven repository. http://repository.jboss.org/maven2/org/jbpm/jbpm4/jbpm/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2948) Resume super process execution in separate transaction

by Alejandro Guizar (JIRA)

Resume super process execution in separate transaction ------------------------------------------------------ Key: JBPM-2948 URL: https://jira.jboss.org/browse/JBPM-2948 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Alejandro Guizar Assignee: Alejandro Guizar Fix For: jBPM 3.2.10 [Description by Brad Davis] Consider a process with forks and joins that internally call sub-processes. Sub-processes wait for a number of minutes doing some stuff, and then they end. If the sub-processes all end at the same time, they try to signal the token for the parent process and get a stale object exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-2422) investigate if logging abstraction should be removed

by Tom Baeyens (JIRA)

investigate if logging abstraction should be removed ---------------------------------------------------- Key: JBPM-2422 URL: https://jira.jboss.org/jira/browse/JBPM-2422 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens Priority: Minor Fix For: jBPM 4.x the current approach is to have a minimal log framework pluggability: ---------------------------------------------------------------------------------------------- 1) jdk logging because we want it to be possible to run pvm without external library dependencies 2) log4j as jboss doesn't include a jdklogging-to-log4j bridge. general links ------------------ http://www.jboss.org/community/wiki/Logging select between these options: ----------------------------------------- 1) always require a jbpm.logging.properties on the classpath. that configures the jdk logging. eithers completely, or with a delegation to log4j in that case our jbpm code can always use the jdk logging. 2) keep it as it is 3) similar solution to seam for facelets: ===http://markmail.org/message/ywamc5yc7hejrlls==================================================================== Subject: Facelets JDK Logging -> JBoss Log4j bridge Actions... From: Pete Muir (pmu...(a)bleepbleep.org.uk) Date: Feb 19, 2008 7:27:50 am List: net.java.dev.facelets.dev As has been discussed many times on the seam forum and facelets mailing list, JBoss AS doesn't have a jdk logger -> log4j generic bridge (I don't know why, and I don't really want to find out) so what Stan did for JSF RI was write a JDK logging filter that would bridge JUL to log4j. I have done the same for Facelets (included as part of jboss-seam-ui.jar, I can factor out the relevant code if anyone wants it) but hit a sight problem. Most logs in facelets are declared protected static final (so I can get at them using reflection) but in DefaultFacelet, CompositionHandler and DecorateHandler they are protected final (so I can't get at them easily as they aren't static). Any chance they could become static? Let me know and I'll file a bug. Code is here http://fisheye.jboss.org/browse/Seam/trunk/ui/src/main/java/org/jboss/sea... Thanks, Pete -- Pete Muir http://in.relation.to/Bloggers/Pete http://www.seamframework.org ============================================================================================================ -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2930) IllegalArgumentException on error path in DispatcherThread

by Per Christian Henden (JIRA)

IllegalArgumentException on error path in DispatcherThread ---------------------------------------------------------- Key: JBPM-2930 URL: https://jira.jboss.org/browse/JBPM-2930 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 4.4 Environment: JBPM 4.4 upgraded from 4.3, JDK 1.6u21. Reporter: Per Christian Henden DispatcherThread waits before retrying to execute a Job when there is an error. If there are multiple failures in a row, the wait period is increased in the following manner: int currentIdleInterval = jobExecutor.getIdleMillis(); //Typically a few seconds while(isActive) { .... catch (Exception e) { ... semaphore.wait(currentIdleInterval); ... currentIdleInterval = currentIdleInterval * 2; ... } } In other words, currentIdleInterval grows without bounds. Eventually the integer currentIdleInterval will overflow and semaphore.wait() will throw java.lang.IllegalArgumentException: timeout value is negative, resulting in a crash. In my case an error occurs because there are timers that refer to inactive executions (because timers that have not fired are not deleted when a subprocess ends in JBPM 4.3). This has left me with some 340 rows in JBPM4_JOB that refers to a non-existing execution. Another aspect of this problem is that the retry-wait can grow to unreasonably large values, for example multiple days, and if my calculations are correct, multiple years. A simple fix is to introduce an upper bound of for example 256 * jobExecutor.getIdleMillis(), and not increase currentIdleInterval above that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
10
0 / 0

[JBoss JIRA] Created: (JBPM-2688) extend ProcessInstanceQuery so that process instances can be searched by their processDefinitionKeys

by Sebastian Schneider (JIRA)

extend ProcessInstanceQuery so that process instances can be searched by their processDefinitionKeys ---------------------------------------------------------------------------------------------------- Key: JBPM-2688 URL: https://jira.jboss.org/jira/browse/JBPM-2688 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.2 Reporter: Sebastian Schneider When using a ProcessInstanceQuery it is possible to search by processBusinessKey and also by processDefinitionId. The ProcessInstanceQuery should be extended so that process instances can also be searched by processDefinitionKeys. This is usel in situations where you want to retrieve all process instances of the same process definition but in different versions. -- 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, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-2938) Missing attributes in jpdl-4.4.xsd

by James Baker (JIRA)

Missing attributes in jpdl-4.4.xsd ---------------------------------- Key: JBPM-2938 URL: https://jira.jboss.org/browse/JBPM-2938 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation, Runtime Engine Affects Versions: jBPM 4.4 Environment: Windows Vista, JBoss EAP 5.0 Reporter: James Baker The 4.4 XSD does not allow the "name" attribute for <object /> or <ref /> elements which means that they cannot be used for HQL activity parameters which require a name. I have noted that if you just ignore the XSD and specify a name anyway it does work (org.jbpm.pvm.internal.wire.descriptor.AbstractDescriptor defines a field "name"). Also it's worth pointing out that neither the user guide or examples provide an example on an HQL activity with a parameter from the execution context. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues October 2010