April 2010 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-2853) Problem in retrieving process variable of serializable objects

by Huisheng Xu (JIRA)

Problem in retrieving process variable of serializable objects -------------------------------------------------------------- Key: JBPM-2853 URL: https://jira.jboss.org/jira/browse/JBPM-2853 Project: jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Runtime Engine Affects Versions: jBPM 4.3 Environment: JDK-1.5.0_20, Maven-2.2.1, Hsqldb, windows xp Reporter: Huisheng Xu Fix For: jBPM 4.x -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPM-2426) mail attachment example

by Alejandro Guizar (JIRA)

mail attachment example ----------------------- Key: JBPM-2426 URL: https://jira.jboss.org/jira/browse/JBPM-2426 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Runtime Engine Reporter: Alejandro Guizar Assignee: Alejandro Guizar Fix For: jBPM 4.1 Provide an example that shows how to attach files to outgoing emails. -- 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, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-1708) CommandServiceBean cannot access UserTransaction

by Thomas Diesler (JIRA)

CommandServiceBean cannot access UserTransaction ------------------------------------------------ Key: JBPM-1708 URL: https://jira.jboss.org/jira/browse/JBPM-1708 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: jBPM 3.3.0 Caused by: org.jbpm.JbpmException: couldn't start JTA transaction at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.java:74) at org.jbpm.persistence.jta.JtaDbPersistenceService.<init>(JtaDbPersistenceService.java:47) at org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory.openService(JtaDbPersistenceServiceFactory.java:63) at org.jbpm.svc.Services.getService(Services.java:156) at org.jbpm.svc.Services.getPersistenceService(Services.java:195) at org.jbpm.JbpmContext.getPersistenceService(JbpmContext.java:622) at org.jbpm.JbpmContext.getGraphSession(JbpmContext.java:566) at org.jbpm.JbpmContext.deployProcessDefinition(JbpmContext.java:173) at org.jbpm.command.DeployProcessCommand.execute(DeployProcessCommand.java:68) at org.jbpm.ejb.impl.CommandServiceBean.execute(CommandServiceBean.java:146) 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:597) at org.jboss.invocation.Invocation.performCall(Invocation.java:359) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) 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) ... 45 more Caused by: org.jbpm.JbpmException: could not retrieve user transaction with name java:comp/UserTransaction at org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory.getUserTransaction(JtaDbPersistenceServiceFactory.java:84) at org.jbpm.persistence.jta.JtaDbPersistenceService.beginJtaTransaction(JtaDbPersistenceService.java:71) ... 68 more -- 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, 8 months

2
25
0 / 0

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

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Alejandro Guizar resolved JBPM-642. ----------------------------------- Resolution: Done > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: jBPM > Issue Type: Feature Request > Components: Runtime Engine > Affects Versions: jBPM 3.2.9 > Reporter: Enric Cecilla > Assignee: Alejandro Guizar > Fix For: jBPM 3.2.x > > Attachments: mylyn-context.zip > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > 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

14 years, 8 months

1
0
0 / 0

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

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Alejandro Guizar updated JBPM-642: ---------------------------------- Original Estimate: 0 minutes Remaining Estimate: 0 minutes Committed a trivial solution to this issue: to lock the parent token parked in a fork node. Later on, the join node unlocks the parent token before it leaves. This solution does not hide the parent token from the application, but does prevent signals from reaching the parent token and making a mess out of the process instance. > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: jBPM > Issue Type: Feature Request > Components: Runtime Engine > Affects Versions: jBPM 3.2.9 > Reporter: Enric Cecilla > Assignee: Alejandro Guizar > Fix For: jBPM 3.2.x > > Attachments: mylyn-context.zip > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > 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

14 years, 8 months

1
0
0 / 0

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

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Alejandro Guizar updated JBPM-642: ---------------------------------- Attachment: mylyn-context.zip > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: jBPM > Issue Type: Feature Request > Components: Runtime Engine > Affects Versions: jBPM 3.2.9 > Reporter: Enric Cecilla > Assignee: Alejandro Guizar > Fix For: jBPM 3.2.x > > Attachments: mylyn-context.zip > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > 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

14 years, 8 months

1
0
0 / 0

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

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Alejandro Guizar updated JBPM-642: ---------------------------------- Fix Version/s: jBPM 3.2.x Affects Version/s: jBPM 3.2.9 > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: jBPM > Issue Type: Feature Request > Components: Runtime Engine > Affects Versions: jBPM 3.2.9 > Reporter: Enric Cecilla > Assignee: Alejandro Guizar > Fix For: jBPM 3.2.x > > > 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

14 years, 9 months

1
0
0 / 0

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

by Alejandro Guizar (JIRA)

[ https://jira.jboss.org/jira/browse/JBPM-642?page=com.atlassian.jira.plugi... ] Alejandro Guizar reopened JBPM-642: ----------------------------------- Assignee: Alejandro Guizar (was: Tom Baeyens) > Signaling RootToken on Fork Node > --------------------------------- > > Key: JBPM-642 > URL: https://jira.jboss.org/jira/browse/JBPM-642 > Project: jBPM > Issue Type: Feature Request > Components: Runtime Engine > Reporter: Enric Cecilla > Assignee: Alejandro Guizar > > 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

14 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues April 2010