[ https://jira.jboss.org/jira/browse/JBPM-1887?page=com.atlassian.jira.plug... ] Bernd Ruecker commented on JBPM-1887: ------------------------------------- Okay, I could reproduce the behavior. If the ExceptionHandler itself throws an exception it can catch, it will hang in an infinitive loop. In my eyes this is a bug and I would resolve it for next jbpm version (even if I think it doesn't affect a lot of people). Unfortunately the CVS-history wasn't importent in the new SVN and my "old" CVS access doesn't work any more (don't know why), so I cannot easily check what has changed and why it was not there in jbpm 3.2.GA. Anyway, I would say, an exception caused by an action executed by exception handler should NOT be handled by the jbpm exception handler. This could be implemented by checking if the exception is set on the ExecutionContext already: GraphElement 280: // If an exception is already set we are in an action of an exception handler // in this case don't give the exception to the handlers but throw it to the client if (executionContext.getException()==null) { // if an exception handler is available raiseException(exception, executionContext); } else { // if there is no parent we need to throw an action exception to the client if (exception instanceof JbpmException) { throw (JbpmException) exception; } else { throw new DelegationException(exception, executionContext); } } What do you guys think? Worked for my local test case. I could add the test case and commit this change if it doesn't break anything of the test suite... Thoughts? -- 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

[ https://jira.jboss.org/jira/browse/JBPM-1887?page=com.atlassian.jira.plug... ] Alejandro Guizar commented on JBPM-1887: ---------------------------------------- The CVS history is available from fisheye: http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/org/jb... Tag jpdl_3_2 is set to revision 1.9, whereas jpdl_3_2_2 is set to 1.12. In GraphElement revision 1.11, the following change was made to method raiseException() 339 349 ExceptionHandler exceptionHandler = findExceptionHandler(exception); 340 350 if (exceptionHandler!=null) { 341 351 executionContext.setException(exception); 342 - exceptionHandler.handleException(executionContext); 352 + exceptionHandler.handleException(this, executionContext); 343 353 isHandled = true; 344 354 } The enclosing changeset is http://fisheye.jboss.com/changelog/JBPM?cs=MAIN:tbaeyens:20070611103928 The related change to ExceptionHandler (1.2) is the cause of this issue: 55 - public void handleException(ExecutionContext executionContext) throws Exception { 55 + public void handleException(GraphElement graphElement, ExecutionContext executionContext) throws Exception { 56 56 if (actions!=null) { 57 57 Iterator iter = actions.iterator(); 58 58 while (iter.hasNext()) { 59 59 Action action = (Action) iter.next(); 60 - action.execute(executionContext); 60 + graphElement.executeAction(action, executionContext); 61 61 } 62 62 } 63 63 } Before, when the action execution threw an exception, the exception would reach GraphElement.raiseException(), which raises it in the *parent* graph element. After the above change, the exception is caught inside GraphElement.executeAction, which raises it in the *same* graph element. I agree an exception should not be handled if the execution context is already handling an earlier exception. Since raiseException() is called from multiple places, it is probably better to move the check inside raiseException(). -- 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

[ https://jira.jboss.org/jira/browse/JBPM-1887?page=com.atlassian.jira.plug... ] Alejandro Guizar commented on JBPM-1887: ---------------------------------------- The CVS history is available from fisheye: http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/org/jb... Tag jpdl_3_2 is set to revision 1.9, whereas jpdl_3_2_2 is set to 1.12. In GraphElement revision 1.11, the following change was made to method raiseException() 339 349 ExceptionHandler exceptionHandler = findExceptionHandler(exception); 340 350 if (exceptionHandler!=null) { 341 351 executionContext.setException(exception); 342 --- exceptionHandler.handleException(executionContext); +++ 352 exceptionHandler.handleException(this, executionContext); 343 353 isHandled = true; 344 354 } The enclosing changeset is http://fisheye.jboss.com/changelog/JBPM?cs=MAIN:tbaeyens:20070611103928 The related change to ExceptionHandler (1.2) is the cause of this issue: 55 -- public void handleException(ExecutionContext executionContext) throws Exception { ++ 55 public void handleException(GraphElement graphElement, ExecutionContext executionContext) throws Exception { 56 56 if (actions!=null) { 57 57 Iterator iter = actions.iterator(); 58 58 while (iter.hasNext()) { 59 59 Action action = (Action) iter.next(); 60 -- action.execute(executionContext); ++ 60 graphElement.executeAction(action, executionContext); 61 61 } 62 62 } 63 63 } Before, when the action execution threw an exception, the exception would reach GraphElement.raiseException(), which raises it in the *parent* graph element. After the above change, the exception is caught inside GraphElement.executeAction, which raises it in the *same* graph element. I agree an exception should not be handled if the execution context is already handling an earlier exception. Since raiseException() is called from multiple places, it is probably better to move the check inside raiseException(). -- 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

[ https://jira.jboss.org/jira/browse/JBPM-1887?page=com.atlassian.jira.plug... ] Bernd Ruecker resolved JBPM-1887. --------------------------------- Fix Version/s: jBPM 3.3.1 GA (was: jBPM 3.3.2 GA ) Resolution: Done -- 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