[JBoss JIRA] Created: (JBPM-1461) rename transition.guardCondition to transition.condition
by Tom Baeyens (JIRA)
rename transition.guardCondition to transition.condition
--------------------------------------------------------
Key: JBPM-1461
URL: https://jira.jboss.org/jira/browse/JBPM-1461
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Tom Baeyens
this is because it's a general purpose condition on the transition. this can be used by activities in a variety of ways. only one the potential interpretations is a guard condition. that's why i think that the name condition for this property is better to indicate the general purpose nature of this condition.
examples of other use cases:
a decision that takes the first condition that evaluates to true
a fork that takes every transition for which the condition evaluates to true
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBPM-1145) Loops realized via a decision node will eventually cause a StackOverflow Exception
by R??diger Schmitz (JIRA)
Loops realized via a decision node will eventually cause a StackOverflow Exception
----------------------------------------------------------------------------------
Key: JBPM-1145
URL: http://jira.jboss.com/jira/browse/JBPM-1145
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.4, jBPM 3.1
Reporter: R??diger Schmitz
Assigned To: Tom Baeyens
Executing a simple, iterative loop implemented with a decision node will cause a StackOverflowException (see below for stacktrace). Apparently the iterative calls are executing using recursive calls. This approach fails if a medium sized loop should be executed (a simple reproducing testcase only reached 161 loop iterations before failing). I see this implementation style as highly problematic when processing medium-sized quantities of input data...
java.lang.StackOverflowError
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891)
at java.lang.ClassLoader.loadClass(ClassLoader.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1926)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:71)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:520)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1627)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentList.iterator(PersistentList.java:115)
at org.jbpm.graph.def.GraphElement.findExceptionHandler(GraphElement.java:358)
at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:326)
at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:343)
at org.jbpm.graph.def.Node.execute(Node.java:332)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
<snip>...a ton of repeating stacktraceelements omitted... <snap>
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:136)
at org.jbpm.graph.node.Decision.execute(Decision.java:145)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.def.Node.leave(Node.java:346)
at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:120)
at com.atos.worldline.kams.workflow.pf.BusinessObjectAccessHandler.doExecute(BusinessObjectAccessHandler.java:114)
at com.atos.worldline.kams.workflow.pf.AbstractBusinessMethodHandler.execute(AbstractBusinessMethodHandler.java:60)
at org.jbpm.graph.def.Action.execute(Action.java:123)
at org.jbpm.graph.def.Action$$FastClassByCGLIB$$7876e90e.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Action$$EnhancerByCGLIB$$889386ac_3.execute(<generated>)
at org.jbpm.graph.def.Node.execute(Node.java:328)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.exe.ExecutionContext.leaveNode(ExecutionContext.java:136)
at org.jbpm.graph.node.Decision.execute(Decision.java:145)
at org.jbpm.graph.def.Node.enter(Node.java:316)
at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:161)
at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$cb94b78_3.enter(<generated>)
at org.jbpm.graph.def.Transition.take(Transition.java:119)
at org.jbpm.graph.def.Node.leave(Node.java:382)
at org.jbpm.graph.def.Node.leave(Node.java:346)
--
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, 4 months
[JBoss JIRA] Created: (JBPM-1417) optimize database clean up inbetween tests
by Tom Baeyens (JIRA)
optimize database clean up inbetween tests
------------------------------------------
Key: JBPM-1417
URL: https://jira.jboss.org/jira/browse/JBPM-1417
Project: JBoss jBPM
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PVM
Reporter: Tom Baeyens
Priority: Critical
ideally we should get to the following situation:
* each package has its own configuration and its own session factory
* all tests with the same session factory should reuse the session factory as much as possible to prevent unnecessary parsing and DB schema creation
* parts of the test suite that use the same session factory should run sequentially
* in between tests of the same part, the database should be cleaned (delete from <table>;) for all tables
* inbetween parts, the db schema should be dropped and the new schema should be created
This should all work in junit test suite and from mvn command line
--
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
16 years, 4 months