jbpm 3.2.x: Reading Timers in wrong order

[camunda]

Hey guys.

Okay, since it is the second customer in a row having problems with this one, I at least wanted to post it here. When parsing the processdefinition, timers are read before all events are read.

This leads to "create-timer" actions being added to the node-enter events BEFORE your own actions. This doesn't make a lot of sense, normally you want your own actions being executed first and the timer created afterwards. From the runtime perspective, it doesn't make any difference (since the timer is started not before the transaciton commits), but with that behavior you could e.g. calculate due dates on the node-enter event (before the time is created).

This is located in the JpdlXmlReader, method "readNode", these two lines:

    readNodeTimers(nodeElement, node);
    readEvents(nodeElement, node);

But I think, there is no way of changing that in the existing jbpm 3.2.x code base, right? Can it break other projects code?

The workaround is to use the create-timer and cancel-timer actions, not nice, but I guess can live with that...

Cheerio

Bernd

[kukeltje]

If there is a risk in things getting screwed up, why not make it configurable with the default being the current behaviour?

[camunda]

Hmm, but that makes it maybe a bit complicated. I would say, either we change it or we leave it....

[aguizar]

Rather than reading timers before or after other events, I'd like to see them read in document order. That way you can control the behavior of the parser from the process document, without requiring a configuration setting.

We are committed to API and database stability; the only flexibility we retain is implementation. We can still make changes like this one provided the release notes reflect it - can you create a JIRA issue?

[camunda]

Jira created: https://jira.jboss.org/jira/browse/JBPM-2696

Actually I am not sure if it has to be that complicated. Since as I said timers are activated always not before committing the transaction, it doesn't make that much sense to have the order to be configurable. Just that you often want to calculate something for the duedate BEFORE the timer is created.

[kukeltje]

[e-mail] wrote:

We are committed to API and database stability; the only flexibility we retain is implementation.

Aren't interfaces contracts about api AND implementation? What is the advantage of a stable api when the implementation changes fundamentally?

[aguizar]

Ronald, I agree that API stability encompasses specifications in the API documentation or the user guide, if any. The user guide describes the attributes and subelements of the timer and event elements, but not the order in which they are read.So far client software could not rely on the parsing order. This update would provide a reliable order.

[aguizar]

Duplicate post - please ignore.

[kukeltje]

Hhhhhmmmm.... does not happen often, but I think I have to disagree, strongly, on this one. At least to a certain extend.

The documention also says nothing about whatever element in the processdefinion is parsed in whatever order. The xsd does not enforce order, so in general it is undefined. Introducing what you say is the same as saying that end nodes should always be the last in the definition if you want the process in between to run and if the end-node is directly after the start node the behaviour is undefined.

Ok, I know I'm exgaggerating a little (ok maybe a lot) but this could result in backwards compatibility issues that are maybe not wanted. So I still think that there should be an option to keep current behaviour.