-
1. Re: jbpm 3.2.x: Reading Timers in wrong order
kukeltje Dec 18, 2009 1:26 PM (in response to camunda)If there is a risk in things getting screwed up, why not make it configurable with the default being the current behaviour? -
2. Re: jbpm 3.2.x: Reading Timers in wrong order
camunda Dec 21, 2009 8:28 AM (in response to kukeltje)Hmm, but that makes it maybe a bit complicated. I would say, either we change it or we leave it.... -
3. Re: jbpm 3.2.x: Reading Timers in wrong order
aguizar Dec 21, 2009 8:57 AM (in response to camunda)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?
-
4. Re: jbpm 3.2.x: Reading Timers in wrong order
camunda Dec 21, 2009 12:00 PM (in response to aguizar)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.
-
5. Re: jbpm 3.2.x: Reading Timers in wrong order
kukeltje Dec 22, 2009 3:24 AM (in response to aguizar)alex.guizar@jboss.com 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?
-
6. Re: jbpm 3.2.x: Reading Timers in wrong order
aguizar Dec 22, 2009 8:10 PM (in response to kukeltje)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.
-
7. Re: jbpm 3.2.x: Reading Timers in wrong order
aguizar Dec 22, 2009 8:13 PM (in response to kukeltje)Duplicate post - please ignore.
-
8. Re: jbpm 3.2.x: Reading Timers in wrong order
kukeltje Dec 23, 2009 7:15 PM (in response to aguizar)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.