[jBPM] - exception on fork getting all outgoing transitions
by Sebastian Herbst
Sebastian Herbst [http://community.jboss.org/people/Herbst] created the discussion
"exception on fork getting all outgoing transitions"
To view the discussion, visit: http://community.jboss.org/message/535160#535160
--------------------------------------------------------------
Hi,
I'm still experimentig with jBPM 4.3 ran in som exeption. The goal is run the jpdl step by step, so i'm trying to get all transitions of the active nodes and signal each time which is taken. This works real good, as long i don't add concurrency. But with this diagramm i'm getting the exceptions org.jbpm.api.JbpmException: no environment to get org.jbpm.pvm.internal.session.RepositorySession.
Here is the jpdl-file:
<?xml version="1.0" encoding="UTF-8"?>
<process name="eTestDoubleFork" xmlns="http://jbpm.org/4.3/jpdl">
<start g="259,3,80,40" name="Start">
<transition to="wait"/>
</start>
<state g="244,93,80,40" name="wait">
<transition g="-39,-20" name="to fork" to="fork1"/>
</state>
<state g="462,191,80,40" name="park">
<transition g="-46,-20" name="to fork2" to="fork2"/>
</state>
<state g="137,345,92,52" name="home">
<transition g="-60,-12" name="to state 3" to="state3"/>
</state>
<end g="311,495,48,48" name="end1"/>
<fork g="266,186,48,48" name="fork1">
<transition g="-41,4" name="toHome" to="home"/>
<transition g="-39,-20" name="toPark" to="park"/>
</fork>
<fork g="478,343,48,48" name="fork2">
<transition g="-50,-20" name="to state1" to="state1"/>
<transition g="18,4" name="to state2" to="state2"/>
</fork>
<state g="290,343,92,52" name="state1">
<transition g="-20,-14" name="to end state1" to="end1"/>
</state>
<state g="457,490,92,52" name="state2">
<transition g="-45,-20" name="to end state2" to="end1"/>
</state>
<state name="state3" g="146,461,92,52">
<transition name="to end state3" to="end1" g="-43,5"/>
</state>
</process>
And here the code I'm running:
Workflow.java
public class Workflow implements Serializable
{
private static Configuration jbpmConfiguration = new Configuration().setResource("my.jbpm.cfg.xml");
private Map<String, Object> variables = new HashMap<String, Object>();
private ProcessEngine processEngine;
private RepositoryService repositoryService;
private ExecutionService executionService;
private NewDeployment newDeployment;
private String deploymentDbid;
private HistoryService historyService;
public Workflow()
{
processEngine = jbpmConfiguration.buildProcessEngine();
repositoryService = processEngine.getRepositoryService();
executionService = processEngine.getExecutionService();
deploymentDbid = addNewDeployment("test/eTestDoubleFork.jpdl.xml");
}
public String addNewDeployment(String jpdl_file)
{
NewDeployment newDeployment = repositoryService.createDeployment().addResourceFromClasspath(jpdl_file);
String deploymentDbid = newDeployment.deploy();
return deploymentDbid;
}
public ProcessInstance startProcessInstance(String processInstanceKey)
{
System.out.println(repositoryService.getResourceNames(deploymentDbid));
ProcessInstance processInstance = executionService.startProcessInstanceByKey(processInstanceKey, variables);
return processInstance;
}
public ProcessInstance nextState(ProcessInstance processInstance, Transition transition)
{
List<Transition> transitions = getTransitiones(processInstance);
if(transitions.contains(transition))
{
Execution execution = searchTransitionExecution(processInstance, transition);
processInstance = executionService.signalExecutionById(execution.getId(), transition.getName());
}
return processInstance;
}
private Execution searchTransitionExecution(ProcessInstance processInstance, Transition transition)
{
Execution mainExecution = processInstance.getProcessInstance();
if(!mainExecution.getExecutions().isEmpty())
{
for(Execution exe : mainExecution.getExecutions())
{
try
{
if(((ExecutionImpl)exe).getActivity().getOutgoingTransitions().contains(transition))
{
mainExecution = exe;
break;
}
}
catch(Exception e)
{
System.out.println(exe.getName() + ":" + e);
}
}
}
return mainExecution;
}
public Set<String> getStateName(ProcessInstance processInstance)
{
if(processInstance.isEnded())
{
return null;
}
else
{
return processInstance.findActiveActivityNames();
}
}
public List<Transition> getTransitiones(ProcessInstance processInstance)
{
Execution execution;
List<Transition> stateList = new ArrayList<Transition>();
for(String exName : processInstance.findActiveActivityNames())
{
execution = processInstance.findActiveExecutionIn(exName);
stateList.addAll(getTransitiones(execution));
}
return stateList;
}
public List<Transition> getTransitiones(Execution execution)
{
List<Transition> list = new ArrayList<Transition>();
ExecutionImpl exeImpl = (ExecutionImpl)execution;
try
{
ActivityImpl activImpl = exeImpl.getActivity();
list = activImpl.getOutgoingTransitions();
}
catch(Exception e)
{
System.out.println(execution.getName() + ":" + e);
}
return list;
}
}
start.java
public class Start
{
public static void main(String[] args)
{
// Setze Workflow-Engine auf
Workflow wf = new Workflow();
// Setze Workflow auf und starte eine Instanz
wf.addNewDeployment("jBPM_to_W3LJ2/eTestDoubleFork.jpdl.xml");
ProcessInstance processInstance = wf.startProcessInstance("eTestDoubleFork");
String processInstanceId = processInstance.getId();
String processDefinitionId = processInstance.getProcessDefinitionId();
System.out.println("1------------------------------");
System.out.println("Befinde mich in State : " + wf.getStateName(processInstance));
List<Transition> transitions = wf.getTransitiones(processInstance);
System.out.println("Ausgehenden Transitionen : " + transitions.toString());
Transition trans = transitions.get(0);
System.out.println("Wähle Transition : " + trans.getName());
processInstance = wf.nextState(processInstance, trans);
System.out.println("Befinde mich nun in State : " + wf.getStateName(processInstance));
System.out.println("2------------------------------");
transitions = wf.getTransitiones(processInstance);
System.out.println("Ausgehenden Transitionen : " + transitions.toString());
trans = transitions.get(0);
System.out.println("Wähle Transition : " + trans.getName());
processInstance = wf.nextState(processInstance, trans);
System.out.println("Befinde mich nun in State : " + wf.getStateName(processInstance));
System.out.println("3------------------------------");
transitions = wf.getTransitiones(processInstance);
System.out.println("Ausgehenden Transitionen : " + transitions.toString());
trans = transitions.get(0);
System.out.println("Wähle Transition : " + trans.getName());
processInstance = wf.nextState(processInstance, trans);
System.out.println("Befinde mich nun in State : " + wf.getStateName(processInstance));
System.out.println("History States : " + wf.getHistoryToString(processInstanceId, processDefinitionId));
}
}
It works until
System.out.println("3------------------------------");
After that line I'm getting not all transitions.
Can anyone hlep me ?
Thanks
Sebastian
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535160#535160]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months
[JBoss Tools] - How Developers should use JBoss Tools JIRA
by Max Andersen
Max Andersen [http://community.jboss.org/people/max.andersen%40jboss.com] modified the document:
"How Developers should use JBoss Tools JIRA "
To view the document, visit: http://community.jboss.org/docs/DOC-12834
--------------------------------------------------------------
JBoss Tools jira is located at https://jira.jboss.org/jira/browse/JBIDE https://jira.jboss.org/jira/browse/JBIDE and its related project JBoss Developer Studio has a jira at https://jira.jboss.org/jira/browse/JBDS https://jira.jboss.org/jira/browse/JBDS
h1. Lifecycle of an issue
Overall the lifecycle of an issue that is supposed to be implemented (i.e. not rejected) the lifecycle is as follows:
1. Someone creates an issue
2. if it is a relevant issue a committer assigns it for a fix version
3. a committer fixes the issue and resolves the issue
4. during QA the issue gets 1. Closed or
2. Reopened if the issue is not fully resolved and then Goto #3
h2. Creation
Anyone can create an issue. When the issue is created it should as a minimum have:
* a *good summary* (selfexplanatory if possible)
* a *Component* to make it show up categorized instead of in the https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hi... "No Component" component which would make it hard to see which components has the most need for attention/workload. If you feel there is no matching component go to the devel list and suggest one.
* *Affects version* so we know which version to reproduce the issue in
* *Description* to allow us to reproduce the issue or understand what the feature is about. Attach projects, output from Help > Report problem, screenshots or even a http://www.jingproject.com/ screencast to illustrate what you want to describe.
Assignment should not happen before you know for sure the committer is going to work on the issue.
h2. Assignment
Only committers/developers should assign the issue. Do not assign the issue to anyone unless that is yourself or you know for sure he or she is supposed to work on it. If all issues are assigned we cannot see which are unassigned and needs attention.
The one who is assigned should also make sure to set:
* the *Fix Version(s)* to indicate when it should be completed, without a Fix Version it will not show up in the https://jira.jboss.org/jira/browse/JBIDE?report=com.atlassian.jira.plugin... Road Map nor https://jira.jboss.org/jira/browse/JBIDE?report=com.atlassian.jira.plugin... Change log
* the *Priority* should be set in context of the Fix Version, i.e. an issue can be trivial to implement but still be a Blocker if it is a must have feature or bug to have for the release.
Note: Since April 1, 2010 we changed the default assignment from "Unassigned" to "Component Lead" meaning component lead's will get notification immidiatly for incoming issues and they should make sure the jira gets processed. If the issue is not yours, reassign to the right component/assignee. If not something that will be done by you, make the issue "Unassigned" and set proper fix version.
h2. Discussions
*Keep description updated* - which means if issue has a discussion what actually should be done all this should be collected in description. That saves time for anyone who is working with this issue to understand what actually should be done and how to verify it. Last thing is useful for QA.
h2. Fixing/Resolving
When an issue gets fixed the developer should make sure to:
* *Add unittests*, any non-trival issue is not fixed and should not be committed before the unittest is there for it
* *List the JIRA URL* in the relevant commit(s) (e.g. https://jira.jboss.org/jira/browse/JBIDE-42 https://jira.jboss.org/jira/browse/JBIDE-42 ) together with a short comment on what was done
* *Resolve* (not Close) the issue
* *Comment* on what was done, i.e. sometimes "Done" is fine but if something were done differently than initially discussed in the jira or one of multiple options were implemented state which one and if some new api/feature was introduced put an explanation on how to use it.
* *Write Test Cases/Scenarious* for QA and users with EXECUTE/ASSERT statements describing what should be tested manually to verify the testcase or *attach relevant screenshots* or *create screencast* to show new functionality.
* *Verify the Component and Fix Version* is correct, remember that if we have branched for doing a release and you fixed the issue in both branches set both related versions (i.e. 3.0.0.beta1 and 3.0.0.cr1), if you only fixed it in one branch/trunk make sure you select the correct version.
h2. QA/Closing/Reopen
During QA a committer or QA engineer verifies the issue following the description and/or EXECUTE/ASSERT instructions and if the issue is completed he should:
* *Verify the Component and Fix Version* is correct
* *Close* the issue
* *Comment* with which build/setup he verified it in
If the issue is not completed then
* *Reopen* the issue
* *Comment* what is not working
* *Assign* it back to the developer who resolved the issue
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-12834]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 7 months
Re: [jboss-user] [JCA] - HornetQ RA integration
by Tim Fox
Tim Fox [http://community.jboss.org/people/timfox] replied to the discussion
"HornetQ RA integration"
To view the discussion, visit: http://community.jboss.org/message/535125#535125
--------------------------------------------------------------
To clarify, this is the problem we have.
AS gets a managed connection and calls getLocalTransaction(), this results internally in the RA creating a transacted local session.
The user does work with that connection, then finished, it gets returned to the pool.
Next user wants an XA connection, AS gets the same cached managed connection, getXAResource is called, but the resource is never enlisted in a tx.
This causes us to use the local transacted session we cached earlier on the connection, but it's transacted, and the behaviour we require is an XA session behaves as non transacted non XA session when not enlisted.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535125#535125]
Start a new discussion in JCA at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months
Re: [jboss-user] [JCA] - HornetQ RA integration
by Jeff Mesnil
Jeff Mesnil [http://community.jboss.org/people/jmesnil] replied to the discussion
"HornetQ RA integration"
To view the discussion, visit: http://community.jboss.org/message/535121#535121
--------------------------------------------------------------
One more question about HornetQ RA,
We argued with tim on the number of session we must keep in our ManagedConnection to handle all use cases (esp. doing JMS work using a non-enlisted XA Session).
Currently, we have 2 sessions:
- 1 XA Session
- 1 regular JMS session which is transacted or not depending on the ConnectionRequestInfo
Tim argues that we need 3 sessions:
- 1 XA Session (to be used when doing work in a enlisted XA tx)
- 1 transacted session (to be used when doing work in a local tx)
- 1 non-transacted session (to be used when doing work from a XA Resource which is not enlisted)
What do you think about this?
Does the connection pool should have partitioned the managed connections based on their transaction types (and 2 sessions are ok)
or should we have 3 sessions and return the correct one ourselves?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/535121#535121]
Start a new discussion in JCA at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 7 months