Engine should throw an exception if it encounters a BPMN element that it does not support

I think the current behavior is somehow better. I think it is a good policy to ignore unknown elements. unless there is a specific element that should be explicitly checked. Does such an element exist ?

I agree that the current policy is easier in general.

@Saeid: you can do that easily by hooking in a BpmnParseListener for that element, which you can use to throw an exception when the parser encounters that element.

It seems confusing to me if I deploy a process with elements that Activiti does not understand and nothing happens, i.e. no error is thrown. At least, there should be a very obvious warning telling me that the process contains unsupported elements.

You have two options:
1. check logs just one time you deploy a new version of workflow xml.
2. make engine throw an exception, the way Joram has mentioned in two post above.

on the other side you are able to run more standard BPMN xml files without needing to tweak them for this specific engine.

Often (very often) such an element is referenced by a sequence flow which will fail then since it cannot find the referenced element. So deploying more generic definitions is only partly true.

I agree with Ronald van Kuijk. In my opinion, silently ignoring unknown elements just delays the problem to when the process is actually executed. And if the solution to a problem is to look at errors in the log, I think it is an unsatisfactory solution.

I'm still not convinced of throwing an exception.
Maybe making the warning in the logs more obvious?

@Ronald: what if the unknown element is parsed as a passtrough, such that there is not the problem of the sequence flows?

@Joram: Then it is like what Etienne says, the flow will not behave like you most likely intended. Finding that deploy time is better then runtime.

In general, from a development perspective, it is better to throw exceptions. BUT...

The goal of the spec is that one BPMN file should be usable by multiple tools. Somewhere I believe it says that tools should ignore the pieces that they don't understand and keep them in tact.

Also the idea is that you write unit tests that point out the problem. It is not as good as deploy time exceptions, but that means it's not worse then a sub-optimal.

We could think of further optimizations by capturing the parsing failures and store them in the process definition somehow. If you then try to instantiate a process instance, then we could list all the problems why this process definition is not executable. But that seems like a lot of work to me.

This is still a too specific issue, please file seperate issues if you have special things in mind. At the moment I think it is quite OK when an exception is thrown and when not. But proof me wrong, but please with concrete issues