[JBoss JIRA] Updated: (JBPM-1449) TagLibraryConfig loadImplicit errors
by Alejandro Guizar (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-1449?page=com.atlassian.jira.plug... ]
Alejandro Guizar updated JBPM-1449:
-----------------------------------
Original Estimate: 0 minutes
Remaining Estimate: 0 minutes
Fix Version/s: jBPM 3.2.9
(was: jBPM 3.3.2)
On Jan 19, 2010 I could still build the standalone distribution, install to JBoss 4.2.3 and see the TagLibraryConfig loadImplicit logs written to System.err and thus printed as ERRORs in the server console. Bumping sun.facelets.version to 1.1.15 eliminated those messages at last. Note that 1.1.15.B1 still printed the errors.
> TagLibraryConfig loadImplicit errors
> ------------------------------------
>
> Key: JBPM-1449
> URL: https://jira.jboss.org/jira/browse/JBPM-1449
> Project: jBPM
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Runtime Engine
> Affects Versions: jBPM 3.2.6.SP1
> Reporter: Len DiMaggio
> Assignee: Alejandro Guizar
> Priority: Minor
> Fix For: jBPM 3.2.9
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> Platform JIRA for project JIRA: JBPM-1065
--
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, 11 months
[JBoss JIRA] Created: (JBPM-1178) Script conditions in transitions are evaluated as expressions by the decision node
by Romain Lamarche (JIRA)
Script conditions in transitions are evaluated as expressions by the decision node
----------------------------------------------------------------------------------
Key: JBPM-1178
URL: http://jira.jboss.com/jira/browse/JBPM-1178
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Environment: Windows XP, JBoss AS 4.2.2GA, MS SQL EXPRESS 2005, Jdk5
Reporter: Romain Lamarche
Assigned To: Tom Baeyens
The decision node does not evaluate scripts in conditional transitions.
Indeed, the execute method of node type decision does not check what type of condition it is.
Listing of the wrong code :
(file Decision.java lines 120-135 in Jbpm Jpdl 3.2.2)
} else {
// new mode based on conditions in the transition itself
Iterator iter = leavingTransitions.iterator();
while (iter.hasNext() && (transition==null)) {
Transition candidate = (Transition) iter.next();
String conditionExpression = candidate.getCondition();
if (conditionExpression!=null) {
Object result = JbpmExpressionEvaluator.evaluate(conditionExpression, executionContext);
if (Boolean.TRUE.equals(result)) {
transition = candidate;
}
}
}
}
The problem is the "JbpmExpressionEvaluator".
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBPM-2752) SpringTransactionInterceptor unnecessarily casts PlatformTransactionManager to AbstractPlatformTransactionManager
by Adam Galloway (JIRA)
SpringTransactionInterceptor unnecessarily casts PlatformTransactionManager to AbstractPlatformTransactionManager
-----------------------------------------------------------------------------------------------------------------
Key: JBPM-2752
URL: https://jira.jboss.org/jira/browse/JBPM-2752
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.x
Environment: Spring DM Server
Reporter: Adam Galloway
In the execute() method of SpringTransactionInterceptor the results of resolveTransactionManager() are cast to an AbstractPlatformTransactionManager and then passed to a TransactionTemplate.
The TransactionTemplate only requires a PlatformTransactionManager and none of the AbstractPlatformTransactionManager methods are referenced anywhere else in the SpringTransactionInterceptor. So it appears that this casting to an AbstractPlatformTransactionManager is unnecessary.
This is causing a problem when using proxied PlatformTransactionManager objects in Spring DM. The proxied object is exposed using the PlatformTransactionManger interface but cannot be cast to an AbstractPlatformTransactionManager, as that is one of the joys of working with proxied OSGI objects.
--
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, 11 months
[JBoss JIRA] Commented: (JBPM-895) null pointer when create new sub process definition
by Victor Ruiz (JIRA)
[ https://jira.jboss.org/jira/browse/JBPM-895?page=com.atlassian.jira.plugi... ]
Victor Ruiz commented on JBPM-895:
----------------------------------
It affects version jBPM 3.2.6 too since I've seen it.
I've used binding='late' attribute in my live environment (since sub-process loading is done by means of jPDL).
I've used Michael Thiele solution in my test environment (since sub-process loading is done programatically).
> null pointer when create new sub process definition
> ---------------------------------------------------
>
> Key: JBPM-895
> URL: https://jira.jboss.org/jira/browse/JBPM-895
> Project: jBPM
> Issue Type: Bug
> Affects Versions: jBPM 3.1.3
> Reporter: Tom Nguyen
> Assignee: Tom Baeyens
> Attachments: DbSubProcessResolver.java
>
>
> I have a problem with my process composition
> Exception happen when deploying process with sub process:
> public void deployProcessDefinition() {
> ProcessDefinition processDefinition = ProcessDefinition.parseXmlResource("main/processdefinition.xml");
> ProcessInstance instance = new ProcessInstance(processDefinition);
> JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
> try {
> jbpmContext.deployProcessDefinition(processDefinition);
> } finally {
> jbpmContext.close();
> }
> }
> java.lang.NullPointerException: can't create a process instance when processDefinition is null
> at org.jbpm.graph.exe.ProcessInstance.<init>(ProcessInstance.java:87)
> at org.jbpm.graph.exe.Token.createSubProcessInstance(Token.java:571)
> at org.jbpm.graph.node.ProcessState.execute(ProcessState.java:109)
> at org.jbpm.graph.def.Node.enter(Node.java:316)
> <?xml version="1.0" encoding="UTF-8"?>
> <process-definition
> xmlns="urn:jbpm.org:jpdl-3.1" name="main">
> <start-state name="start">
> </start-state>
> <end-state name="end"></end-state>
> <process-state name="sub">
> <sub-process name="sub"/>
> </process-state>
> </process-definition>
> This is my sub process:
> <?xml version="1.0" encoding="UTF-8"?>
> <process-definition
> xmlns="urn:jbpm.org:jpdl-3.1" name="sub">
> <start-state name="start">
> </start-state>
> <end-state name="end"></end-state>
> </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
14 years, 11 months
[JBoss JIRA] Created: (JBPM-2754) Execution lost when using nested forks/parallel gateways
by Joram Barrez (JIRA)
Execution lost when using nested forks/parallel gateways
---------------------------------------------------------
Key: JBPM-2754
URL: https://jira.jboss.org/jira/browse/JBPM-2754
Project: jBPM
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Joram Barrez
Assignee: Tom Baeyens
Fix For: jBPM 4.x
Attachments: nested_parallel_gateway_problem.jpg
Using nested forks and automatic activities causes an execution to be 'lost':
Take the following example:
start --> fork -> autom act. -> inner join
-> autom act. -> inner join --> outer join
-> wait stat -> outer join
When the first autom act. is finished, the execution arrives in the inner join.
When the second autom act is finished, the second execution arrives in the inner join
Following code is executed (in the Join):
ExecutionImpl outgoingExecution = null;
if (concurrentRoot.getExecutions().size() == 0) {
outgoingExecution = concurrentRoot;
outgoingExecution.setState(Execution.STATE_ACTIVE_ROOT);
} else {
outgoingExecution = concurrentRoot.createExecution();
outgoingExecution.setState(Execution.STATE_ACTIVE_CONCURRENT);
}
The first if will be taken. BUT conceptually the else clause should be taken. The problem is here that concurrentRoot.getExecutions.size() is 0, because the execution going to the wait state isn't created yet.
So for this process, you could make it work by putting the transition toi the wait state first, and the other transitions to the inner join afterwards. That way, when the inner join is handled, the child execution exists and the else clause will be taken.
--
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, 11 months