March 2009 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2085) Release jBPM 3.2.5.SP3

by Alejandro Guizar (JIRA)

Release jBPM 3.2.5.SP3 ---------------------- Key: JBPM-2085 URL: https://jira.jboss.org/jira/browse/JBPM-2085 Project: JBoss jBPM Issue Type: Release Security Level: Public (Everyone can see) Components: Productization Reporter: Alejandro Guizar Assignee: Alejandro Guizar Fix For: jBPM 3.2.6 GA -- 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

15 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPM-2096) EJB reference in JSF web console is broken

by Alejandro Guizar (JIRA)

EJB reference in JSF web console is broken ------------------------------------------ Key: JBPM-2096 URL: https://jira.jboss.org/jira/browse/JBPM-2096 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Console Affects Versions: jBPM 3.2.6 GA Reporter: Alejandro Guizar Assignee: Alejandro Guizar Priority: Blocker Fix For: jBPM 3.2.6 GA JSF console is broken. Timer creation fails with the exception below. javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: ejb not bound] at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1215) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:758) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:774) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627) at javax.naming.InitialContext.lookup(InitialContext.java:409) at org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory.lookup(EntitySchedulerServiceFactory.java:54) at org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory.getTimerEntityHome(EntitySchedulerServiceFactory.java:43) EJB reference ejb/TimerEntityBean in jboss-web.xml points to an unexisting bean. This had been fixed in jsf-console 3.2.6.GA but somehow got reintroduced in 3.2.6.SP1. -- 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

15 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2088) The list of tasks for process cannot be obtained

by Jiri Pechanec (JIRA)

The list of tasks for process cannot be obtained ------------------------------------------------ Key: JBPM-2088 URL: https://jira.jboss.org/jira/browse/JBPM-2088 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Console Affects Versions: jBPM-3.2.5.SP3 Environment: SOA-P 4.3 CP01 CR3 Reporter: Jiri Pechanec Priority: Blocker Select the process and click on tasks (URL http://localhost:8080/jbpm-console/app/procdef.jsf?id=1&view=task) The result is an exception Error loading task list: An exception of type "org.hibernate.exception.DataException" was thrown. The message is: could not execute query >From log Error loading task list: An exception of type "org.hibernate.exception.DataException" was thrown. The message is: could not execute query Will reproduce with higher log level -- 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

15 years, 9 months

4
15
0 / 0

[JBoss JIRA] Created: (JBPM-2086) org.jbpm.db.JbpmSchemaDbTest.testCleanSchema is failing with SOA 4.3 CP01 libraries

by Jiri Pechanec (JIRA)

org.jbpm.db.JbpmSchemaDbTest.testCleanSchema is failing with SOA 4.3 CP01 libraries ----------------------------------------------------------------------------------- Key: JBPM-2086 URL: https://jira.jboss.org/jira/browse/JBPM-2086 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jBPM-3.2.5.SP3 Environment: hsqldb, all platforms Reporter: Jiri Pechanec java.lang.NullPointerException at org.hibernate.mapping.ForeignKey.isPhysicalConstraint(ForeignKey.java:125) at org.jbpm.db.JbpmSchema.getCleanSql(JbpmSchema.java:99) at org.jbpm.db.JbpmSchema.cleanSchema(JbpmSchema.java:189) at org.jbpm.db.JbpmSchemaDbTest.testCleanSchema(JbpmSchemaDbTest.java:39) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at org.jbpm.AbstractJbpmTestCase.runTest(AbstractJbpmTestCase.java:57) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) -- 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

15 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JBPM-1959) Release jBPM 3.3.2 GA

by Thomas Diesler (JIRA)

Release jBPM 3.3.2 GA --------------------- Key: JBPM-1959 URL: https://jira.jboss.org/jira/browse/JBPM-1959 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Productization Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: jBPM 3.3.1 GA -- 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

15 years, 9 months

2
5
0 / 0

[JBoss JIRA] Updated: (JBPM-2087) Verify high volumn job executions with rollback

by Thomas Diesler (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-2087?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBPM-2087: --------------------------------- Security: (was: JBoss Internal) Priority: Major (was: Critical) > Verify high volumn job executions with rollback > ----------------------------------------------- > > Key: JBPM-2087 > URL: https://jira.jboss.org/jira/browse/JBPM-2087 > Project: JBoss jBPM > Issue Type: Task > Components: Core Engine > Reporter: Thomas Diesler > Fix For: jBPM 4.0.x > > > Use JMS instead of DBMS for the store of Jobs. In this case, a Job is not taken by multi-JobExecutors completely. > The configration is mentioned by jBPM Reference Guide in SOA Platform. > http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.GA/html-single/JB... > --- Discussion Summary --- > There are two separate places where locking is an issue. > * Job acquisition > * Join node > The join node already supports pessimistic locking, whereas job acquisition *under the job executor* does not. On the other hand, under JMS, job acquisition does not exhibit any locking issue because each job is a separate message. The container deals with distributing the messages among the pool of JobListenerBean instances. > Using JMS will remove the clashes, at least from the perspective of the job executor. Supporting the JMS feature negates the need for pessimistic locking during job acquisition. > Given the above points, if JBPM-1952 is fully supported then JBPM-1953 becomes unnecessary. -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-2043) Add jBPM performance test coverage

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-2043?page=com.atlassian.jira.plug... ] Alejandro Guizar updated JBPM-2043: ----------------------------------- Fix Version/s: jBPM-3.2.5.SP3 (was: jBPM-3.2.5.SP2) > Add jBPM performance test coverage > ---------------------------------- > > Key: JBPM-2043 > URL: https://jira.jboss.org/jira/browse/JBPM-2043 > Project: JBoss jBPM > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Productization > Affects Versions: jBPM 3.2.5 GA > Environment: SOA 4.3.0 CP01 CR2 > Reporter: Pavel Macik > Assignee: Alejandro Guizar > Fix For: jBPM-3.2.5.SP3, jBPM 3.2.6 GA > > > Performance of jBPM has dropped significantly according to > http://hudson.qa.jboss.com/hudson/view/SOA-Performance/job/SOA-Platform-P... > Other performance has not changed much so the performance drop is isolated to jBPM. -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-642) Signaling RootToken on Fork Node

by Ronald van Kuijk (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Ronald van Kuijk commented on JBPM-642: --------------------------------------- I agree with you, but I think Tom does not disagree. He mentioned to bare this in mind for the 4.0 release. But might be good to mention this in the dev forum (not sure if he receives comments on closed issues) > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Enric Cecilla > Assignee: Tom Baeyens > > Giving the following processdefinition: > *start->fork->a->join->end > ->b ^ > When RootToken is on Fork node trying to signal again the RootToken actually moves the token to one branch state, then RootToken can be signalled til it is on the Join node. At that moment it can be signalled again and it leaves the Join node. > pi.signal(); > assertEquals( "fork", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "b", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "join", pi.getRootToken().getNode().getName() ); //true > Does it makes any sense being able to signal a RootToken on Fork node which has children on every branch? From my point of view signalling on that condition should throw and Exception. Only child tokens should be allowed to signal since "real" tasks are on child tokens -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-642) Signaling RootToken on Fork Node

by Joram Barrez (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Joram Barrez commented on JBPM-642: ----------------------------------- I know that this issue is closed, but I disagree with the current implementation. - It should not be possible to signal a parent token that is in a fork. For the end-user this fork-token shouldn't even 'exists' (ie its in fact an implementation detail). - When using superstates to divide the process in phases, this also causes problems when using the token collection to check the current process phases: ie. the 'real tokens will be in a certain phase, but the parent token is still stuck in the fork (and gives, from a business-wise view an incorrect result). This can easiliy be hacked around be checking the node type of the token ... but that should not be done in the first place ... > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Enric Cecilla > Assignee: Tom Baeyens > > Giving the following processdefinition: > *start->fork->a->join->end > ->b ^ > When RootToken is on Fork node trying to signal again the RootToken actually moves the token to one branch state, then RootToken can be signalled til it is on the Join node. At that moment it can be signalled again and it leaves the Join node. > pi.signal(); > assertEquals( "fork", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "b", pi.getRootToken().getNode().getName() ); //true > pi.signal(); > assertEquals( "join", pi.getRootToken().getNode().getName() ); //true > Does it makes any sense being able to signal a RootToken on Fork node which has children on every branch? From my point of view signalling on that condition should throw and Exception. Only child tokens should be allowed to signal since "real" tasks are on child tokens -- 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

15 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1961) Update to GPD 3.1.7

by Thomas Diesler (JIRA)

Update to GPD 3.1.7 ------------------- Key: JBPM-1961 URL: https://jira.jboss.org/jira/browse/JBPM-1961 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Productization Reporter: Thomas Diesler Assignee: Koen Aers Fix For: jBPM 3.3.1 GA -- 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

15 years, 9 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues March 2009