[JBoss JIRA] Created: (JBPM-1115) Broken datamodel when a detached ProcInst is saved
by Britt Miner (JIRA)
Broken datamodel when a detached ProcInst is saved
--------------------------------------------------
Key: JBPM-1115
URL: http://jira.jboss.com/jira/browse/JBPM-1115
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Reporter: Britt Miner
Assigned To: Tom Baeyens
I've noticed (accidentally of course, -ahem-) that if you attempt to call jbpmContext.save(processInstance) on a pi that was loaded outside of the current session, Hibernate will save a new pi with a new Id--however it will reference the same rootToken, etc. as the original pi, and all kinds of unexpected behavior quietly ensues.
Of course, loading a fresh copy of the pi immediately before you do anything with it avoids the problem; however, a lot of serious data integrity hangs on remembering to do that every time. (for instance, when a pi being viewed in a UI is injected into an action component, the programmer must remember to load up a fresh copy before working on it.)
Since failing to re-load a detached pi can result in what seems to be a broken jBPM data model, jBPM should probably be doing something itself to avoid the problem.
I think there are possibly two ways to prevent this from happening:
1) Simply changing the HibernateSaveOperation.save(processInstance) method to saveOrUpdate() seems to perform cleanly.
2) Do a check on the pi, and throw an error if it doesn't belong to the current hibernate session.
--
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, 1 month
[JBoss JIRA] Created: (JBPM-1173) Fork Node doesn't support conditions on Transitions
by Britt Miner (JIRA)
Fork Node doesn't support conditions on Transitions
---------------------------------------------------
Key: JBPM-1173
URL: http://jira.jboss.com/jira/browse/JBPM-1173
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2
Reporter: Britt Miner
Assigned To: Tom Baeyens
Documentation does not clearly provide any limits to where conditions on Transitions can be used, but the Fork Node doesn't support Transition conditions. For instance
<fork name='FORK_1' >
<transition name='t1' to='NODE_A'>
<condition>#{false}</condition>
</transition>
<transition name='t2' to='NODE_B'/>
</fork>
will fail with a "transition condition #{false} evaluated to 'false'" error when the fork attempts to take transition 't1'. Why provide for this? Someone might want to:
<fork name='FORK_1' >
<transition name='startMyProject' to='...'/>
<transition name='orderEngine to='...'>
<condition>#{needsEngine}</condition>
</transition>
<transition name='orderWheels to='...'>
<condition>#{needsWheels}</condition>
</transition>
...etc...
</fork>
Correcting the issue is as simple as making the following change to org.jbpm.graph.node.Fork.java:
// BRITT --replace the following line with the code below
// to check conditions before adding valid transitions...
//transitionNames = getLeavingTransitionsMap().keySet(); //original line
Iterator iter = leavingTransitions.iterator();
while (iter.hasNext()) {
Transition candidate = (Transition) iter.next();
String conditionExpression = candidate.getCondition();
if (conditionExpression != null) {
Object result = JbpmExpressionEvaluator.evaluate(conditionExpression, executionContext);
if (Boolean.TRUE.equals(result)) {
transitionNames.add(candidate.getName());
}
}else{
transitionNames.add(candidate.getName());
}
}
if (transitionNames.size() == 0) {
transitionNames.add(this.getDefaultLeavingTransition().getName());
this.getDefaultLeavingTransition().removeConditionEnforcement();
log.warn("All transition conditions have evaluated to 'false'. Taking the default transition.");
}
// --BRITT
--
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, 1 month
[JBoss JIRA] Created: (JBPM-1688) jbpm-console and .par upload
by Eric Cartman (JIRA)
jbpm-console and .par upload
----------------------------
Key: JBPM-1688
URL: https://jira.jboss.org/jira/browse/JBPM-1688
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Interface
Affects Versions: JBossBPM-3.3.1
Reporter: Eric Cartman
Priority: Minor
An usability issue, when you try to upload a processdefinition.xml, there's no indication or validation to ask for a .par file.
You only get a weird error "org.jbpm.jpdl.JpdlException" was thrown. The message is: [[ERROR] no processdefinition.xml inside process archive]".... and no other indication.
PD: I've found it, after I've realized at JBossEsb, that all quickstarts/bpm_orchestrations have changed and there's no other way to deploy a process (avoiding ant and eclipse).
Thanks,
Eric
--
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, 1 month
[JBoss JIRA] Created: (JBPM-1455) configuration-property does not work if the method is declared in a super class
by Alejandro Abdelnur (JIRA)
configuration-property does not work if the method is declared in a super class
-------------------------------------------------------------------------------
Key: JBPM-1455
URL: https://jira.jboss.org/jira/browse/JBPM-1455
Project: JBoss jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core Engine
Environment: all
Reporter: Alejandro Abdelnur
If an ActionHandler is used with config-type set to configuration-property it throws an exception if the setConfiguration(String s) method is declared in a super class of the instanciated class. The log reports:
----------
Caused by: java.lang.NoSuchMethodException: *****.TestWorkflowEngine$MyTAsyncActionHandler.setConfiguration(java.lang.String)
at java.lang.Class.getDeclaredMethod(Class.java:1909)
at org.jbpm.instantiation.ConfigurationPropertyInstantiator.instantiate(ConfigurationPropertyInstantiator.java:41)
... 46 more
---------
The code it should use the getMethod() instead of the getDeclaredMethod()
--
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, 1 month
[JBoss JIRA] Created: (JBPM-1126) ProcessDeifnition substates load into top level node list
by James Violette (JIRA)
ProcessDeifnition substates load into top level node list
---------------------------------------------------------
Key: JBPM-1126
URL: http://jira.jboss.com/jira/browse/JBPM-1126
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.4
Environment: ANY
Reporter: James Violette
Assigned To: Tom Baeyens
Priority: Minor
The ProcessDefinition.hbm.xml nodes list must have a where clause to avoid loading substate nodes into the top level node list.
The released nodes list definition
<list name="nodes" cascade="all">
<cache usage="nonstrict-read-write"/>
<key column="PROCESSDEFINITION_" />
<list-index column="NODECOLLECTIONINDEX_" />
<one-to-many class="org.jbpm.graph.def.Node" />
</list>
should be
<list name="nodes" cascade="all" where="superstate is null" >
<cache usage="nonstrict-read-write"/>
<key column="PROCESSDEFINITION_" />
<list-index column="NODECOLLECTIONINDEX_" />
<one-to-many class="org.jbpm.graph.def.Node" />
</list>
--
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, 1 month