November 2009 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2546) creating URL with processresource failes

by Hans Guldager Knudsen (JIRA)

creating URL with processresource failes ---------------------------------------- Key: JBPM-2546 URL: https://jira.jboss.org/jira/browse/JBPM-2546 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 3.2.x Environment: jBPM 3.2.X, ESB 4.6, AS 5.1 Reporter: Hans Guldager Knudsen Hi! If I load a resouce inside an ActionHandler i get an URL with the "protocolresouce" protocol - eg : URL resouceUrl = Thread.currentThread().getContextClassLoader().getResource("resource.txt"); gives me : processresource://recieve_bussiness_msg/classes/classes/resource.txt But if I try to create an URL with the same form URL recreatedUri = new URL( "processresource://recieve_bussiness_msg/classes/classes/resource.txt" ); I get an : java.net.MalformedURLException: unknown protocol: processresource at java.net.URL.<init>(URL.java:574) It seems that there is no java.net.URLStreamHandler to handle the protocol.. I will attach example of how this could be implemented. -- 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

13 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2588) Attribute for tag decision to validate conditions of transitions

by Wojtas Koziej (JIRA)

Attribute for tag decision to validate conditions of transitions ---------------------------------------------------------------- Key: JBPM-2588 URL: https://jira.jboss.org/jira/browse/JBPM-2588 Project: jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Wojtas Koziej My proposition is to extend evaluation of condition when selecting leaving transitions <decision condition-evaluation="strict|first-matching|???"> .... </decision> condition-evaluation (or similar attribute) meaning: * strict - all conditions are evaluated, lets name N as number of conditions which evaluates to true. If N != 1 jBPM raise exception. Transitions without conditions are not allowed * first-matching - jBPM evaluates conditions and leave when find first which evaluate to true. If there is no such transition jBPM raise exception. Transitions without conditions are allowed and evaluates to true. * ??? (I don't no how to name it) - this is default and makes that jBPM behaves as described in current documentation : "So first, all transitions with a condition are evaluated. If one of those evaluate to true, that transition is taken. If no transition with a condition resolves to true, the default transition (=the first one) is taken" It will be very helpful during development and testing. -- 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

13 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-2589) SuperState - StaleObjectStateException when timer signals the token

by Adrian Apthorp (JIRA)

SuperState - StaleObjectStateException when timer signals the token ------------------------------------------------------------------- Key: JBPM-2589 URL: https://jira.jboss.org/jira/browse/JBPM-2589 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.6.SP1 Environment: Win XP, HSQL, JBOSS 4.2.3 Reporter: Adrian Apthorp When I configure a timer on a superstate a StaleObjectStateException is raised when the timer is fired. org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#578] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1765) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2407) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:247) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86) at com.arjuna.ats.arjuna.AtomicAction.end(AtomicAction.java:216) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:240) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:501) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138) at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527) at org.jboss.ejb.Container.invoke(Container.java:960) at org.jboss.ejb.txtimer.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99) at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:561) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) In the following example the timer works correctly on the state node but fails on the superstate timer. Also, it seems that the timer fires for both sub-states (the message is reported twice). When I remove one of the substates the exception still occurs with the message reported once. <state name="State 1"> <timer duedate="20 seconds" repeat="20 seconds" name="late leaving"> <script> System.out.println("What are we waiting for ? "); </script> </timer> <transition to="Moving" name="depart"></transition> </state> <super-state name="Moving"> <state name="Stopped"> <transition to="Started" name="start"></transition> </state> <state name="Started"> <transition to="Stopped" name="stop"></transition> </state> <timer duedate="30 seconds" repeat="30 seconds"> <script> System.out.println("We're late "); </script> </timer> <transition to="end-state1" name="arrive"></transition> </super-state> -- 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

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-2602) jBPM , Drools, Seam 2.2 - Transition issue

by Gary Lamperillo (JIRA)

jBPM , Drools, Seam 2.2 - Transition issue ------------------------------------------ Key: JBPM-2602 URL: https://jira.jboss.org/jira/browse/JBPM-2602 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jBPM 3.2.7 Environment: Seam 2.2, jBPM and Drools 5 Reporter: Gary Lamperillo When using the DroolsDecisionHandler, only one transition from a rule is allowed, when a second transition is used, the following error is received: [ProxyWarnLog] Narrowing proxy to class org.jbpm.graph.node.EndState - this operation breaks == The error should not be received, since the transition is very similar, two rules have been created. When only the first rule is used the one transition works fine. the addition of the second rule with the second transition from the same package in the working memory causes this issue. here is the process definition: <process-definition name="jbpm_to_rules" xmlns="urn:jbpm.org:jpdl-3.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jbpm.org:jpdl-3.2 http://jbpm.org/xsd/jpdl-3.2.xsd" > <start-state name="start"> <transition to="approval"> <action expression="#{bpmCreditList.start}"/> </transition> </start-state> <decision name="approval"> <handler class="org.jboss.seam.drools.DroolsDecisionHandler"> <workingMemoryName>creditRulesWorkingMemory</workingMemoryName> <assertObjects> <element>#{creditScore}</element> </assertObjects> </handler> <transition name="not-preferred-customer" to="done2"> <action expression="#{bpmCreditList.transitionNPC}"/> </transition> <transition name="modified-score" to="modified-score"> <action expression="#{bpmCreditList.approved}"/> </transition> </decision> <end-state name="done2"> <event type="node-enter"> <action>expression="#{bpmCreditList.end}"/> </action> </event> </end-state> <end-state name="modified-score"> </end-state> <task-node name="done" end-tasks="true"> <task name="nopreferred" description="Review order" > <assignment pooled-actors="reviewers"/> </task> <transition name="done2" to="done2"/> </task-node> </process-definition> -- 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

13 years, 6 months

4
6
0 / 0

[JBoss JIRA] Created: (JBPM-2633) Migration guide between supported versions

by Alejandro Guizar (JIRA)

Migration guide between supported versions ------------------------------------------ Key: JBPM-2633 URL: https://jira.jboss.org/jira/browse/JBPM-2633 Project: jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Alejandro Guizar One customer has brought to my attention that migrating between jBPM 3 maintenance releases is an uncertain procedure due to the lack of a formal migration guide. jBPM should provide documentation on how to upgrade from one supported version to another (e.g. from 3.2.2 to 3.2.5.SP5 to 3.2.8). -- 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

13 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPM-2656) JAAS configuration within jBPM 3.2.8 not in sync

by MohReece (JIRA)

JAAS configuration within jBPM 3.2.8 not in sync ------------------------------------------------ Key: JBPM-2656 URL: https://jira.jboss.org/jira/browse/JBPM-2656 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 3.2.8 Reporter: MohReece In the jboss-service.xml file (from the /deploy/server/default/deploy/jbpm/jbpm-service.sar/META-INF/ directory) the name attribute of the jaas:application-policy tag is set to 'jbpm-console'. In the jboss-web.xml (from the /deploy/server/default/deploy/jbpm/jsf-console.war/WEB-INF/ directory) the value for the security-domain tag is set to 'java:/jaas/soa'. This means that when the contents of the /deploy/ directory are copied as-is to an appropriate directory on an application server (as tested on JBoss EAP 4.3) it will not be possible to log in at the jBPM console. It is simply solved by synching these two values (e.g. set the jaas:application-policy tag name attribute to 'soa'). -- 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

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-1170) Multiple Timers with same name on Node end prematurely

by David Roberts (JIRA)

Multiple Timers with same name on Node end prematurely ------------------------------------------------------ Key: JBPM-1170 URL: http://jira.jboss.com/jira/browse/JBPM-1170 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.2 Environment: Jbpm 3.2.2, Tomcat 5.028, MySQL 5.0 Reporter: David Roberts Assigned To: Tom Baeyens When you have multiple Tasks on a Node, and each task has a Timer called, for example, "Reminder". Lets say each timer is set to repeat every 24 hours. If you complete one of the Tasks on the node, the Timer called "Reminder" on that task instance ends, but so does every other timer for all other tasks on that node with the name "Reminder". Surely this should not happen? You could avoid this by naming each Timer differenty, example "Reminder 1", "Reminder 2". But the problem may still happen if you have multiple task instances of the SAME task. Then the name of the Reminders will still be the same, so they will all end when completing one of the task instances. -- 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

13 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (JBPM-1166) fix SEAM timer transaction integration

by Tom Baeyens (JIRA)

fix SEAM timer transaction integration -------------------------------------- Key: JBPM-1166 URL: http://jira.jboss.com/jira/browse/JBPM-1166 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens -- 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

13 years, 6 months

4
19
0 / 0

[JBoss JIRA] Created: (JBPM-1140) Empty <handler> element in <decision> cause org.jbpm.graph.def.DelegationException

by Rafa? ?ukowski (JIRA)

Empty <handler> element in <decision> cause org.jbpm.graph.def.DelegationException ---------------------------------------------------------------------------------- Key: JBPM-1140 URL: http://jira.jboss.com/jira/browse/JBPM-1140 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Rafa? ?ukowski Assigned To: Tom Baeyens Priority: Trivial That is my first issue, forgive me any mistakes and possible redundancy or duplication;) Using graphical designer I've created process file with empty <handler> : <decision name="decision1"> <handler></handler> <transition to="optional" name="to optional"></transition><transition to="first" name="to optional"></transition> </decision> And this is not working (org.jbpm.graph.def.DelegationException). After deleting <handler></handler> process is running correctly. Don't know if this is error in engine or in designer. Maby this kind of decision node is incorrect, and then designer should avoid this situation. My opinion is that engine should ignore empty handlers and go on without errors... -- 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

13 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPM-1118) Unexpected behavier of LoggingConfigDbTest

by Jan-Philipp Bolle (JIRA)

Unexpected behavier of LoggingConfigDbTest ------------------------------------------ Key: JBPM-1118 URL: http://jira.jboss.com/jira/browse/JBPM-1118 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Jan-Philipp Bolle Assigned To: Tom Baeyens Priority: Trivial It looks like that the LoggingConfigDbTest is not working. I added in nologging.jbpm.cfg.xml the org.jbpm.logging.db.DbLoggingServiceFactory. Now I assume that the test must fail because jBPM is configured to use the loggingservice. But the test still work (is green). -- 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

13 years, 6 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues November 2009