Ok, so after digging through code trying to find some way to get the node name from the passed WorkItem in the SignallingTaskHandlerDecorator for then to put together the event-type I realised that e.g. in the org.jbpm.bpmn2.xml.BoundaryEventHandler#handleSignalNode method, this event-type manipulation is not done:
I changed the Boundary event to simply send a "Signal" instead of an "Error" and now it works.
Still I would prefer to have the Error Signal there, as it makes it more clear what it actually does. I leave the question unanswered for now.
instead of using the signal decorator (which is more suitable when you try to signal another type of catching events than errors) you can reply on the handleException logic that is provided by AbstractLogOrThrowWorkItemHandler, just make sure you custom handler extends it and invokes handleException in case of an error. With that it should directly invoke your error boundary event. There you have to ways of specifying the matching criteria, by exception class name or simply catch all. See this process definition and this test case for some sample usage.
when it comes to eclipse modeler, please file a bug report in eclipse bugzilla for the modeler so it gets added. Maybe it is only a matter of configuration what elements are supported somewhere in the configuration of the tool.
Thanks for your reply!
I tried to follow your advise and throw the org.jbpm.bpmn2.handler.WorkItemHandlerRuntimeException instead of signalling directly. That works to a certain degree, but again I'm having difficulties catching the correct errorCode in the Boundary Event, or how you put it: the "matching criteria".
I loaded the process definition you provided and just changed the implementation class of the "Service Task" handler to a very simple one, which basically just throws an exception using the handleException method. I guess the only relevant part is this:
Here's how it fails:
org.jbpm.workflow.instance.node.WorkItemNodeInstance#internalTrigger line 131
String exceptionName = e.getClass().getName();
which is the name of the exception. From here on it tries to resolve an exception handler using this name as parameter and "ExceptionScope" as contextId.
Eventually I end up in org.jbpm.process.core.context.exception.ExceptionScope#getExceptionHandler.
The mapping key is WsError, the ErrorCode specified in the process, and the key it's looking up, is again the exceptions name.
So the only way I got this example to work, was to set the errorCode in the process to the expected exceptions name, which is not the case in the test-process you provided. Is this how it should be?
Thanks and cheers,
Espen, what version are you using? There where improvements in error handling area post 6.0.1 release so if you're not on 6.1.0 then you might be missing these improvements.
In general, you should be able to specify structureRef attribute on the error element of bpmn2 that actually refers to the exception type you expecting for that error, if it is not set all exception should be caught by the attached error event. The first one is used in the example I linked.
Again, thanks for the reply. That's what I was expecting concerning the structureRef attribute. But didn't seem to work, will try later on with 6.1.
Thanks for your help!