Hi SCXML developers and users,

This is a follow-up on the current status of the incoming 'breaking changes'.

Good news: the trunk is stable again :)

I've just committed the last set of intended changes through SCXML-213 [1], SCXML-221 [2] and SCXML-222 [3].

I invite anyone interested to checkout and update to the latest trunk and try and test it out yourself.

But be aware that there *are* important changes.

Some of the APIs changed, although it depends on how much you've been extending/customizing Commons SCXML if you'll have to adjust your code base or not. Most significant probably in that regard are the changes to the EventDispatcher interface and the *removal* of the SimpleScheduler, which has been 'collapsed' in the now much more complete SimpleDispatcher class.

More invasive probably are the possible changes in the SCXML document you might have to make, specifically if you've been using the Data() xpath builtin function, which was re-implemented and changed on signature (now only taking one instead of two parameters).

Furthermore, a new Location() xpath builtin has been added, which you now *must* use instead of the Data() function for location expressions.

Finally, one specific behavioral change of the <send> action is important to note (below copying the comment from SCXML-213):

The <send> action without a specified delay used to deliver the event through the internal I/O event queue. This however was in violation of the specification (unless target="#_internal" is specified, which wasn't supported yet). This behavior now has been changed to be in compliance with the specification, so such <send> actions will now deliver the event through the external I/O event queue. This is important, because the Commons SCXML executor will NOT automatically process external events itself: you'll have to invoke SCXMLExecutor.triggerEvents() for that manually! If you used such <send> actions without a specified delay, be aware this WILL cause a behavioral change in your SCXML execution!! You either have to now handle such events manually, like described above, OR specify <send target="#_internal" ...> (which now IS supported) to retain the earlier behavior.

And as an extra, I've added support for the "null" datamodel AND the SCXML IRP test cases [4].

With these many changes, the current online documentation is really no longer up-to-date anymore. I'll focus on updating the documentation shortly, after I returned from the ApacheCon EU in Budapest next week. Until then, either hold off diving into the 'latest greatest' or else dive into the code and the unit tests to figure out how/what :)

Kind regards,
Ate

p.s. If anyone is at the ApacheCon next week, I'd love to meet you there. Just ping me through email. Or even better: you can 'find me' when/after I've done my Commons SCXML presentation on Monday morning ;)

[1] https://issues.apache.org/jira/browse/SCXML-213
[2] https://issues.apache.org/jira/browse/SCXML-221
[3] https://issues.apache.org/jira/browse/SCXML-212
[4] http://www.w3.org/Voice/2013/scxml-irp/


On 2014-10-27 01:35, Ate Douma wrote:
Hi SCXML developers and users,

This is a heads-up for everyone using the current SCXML 2.0 trunk for their
projects.

Please checkout issue https://issues.apache.org/jira/browse/SCXML-213 which I
just created, which will requires some extensive refactoring and *breaking*
changes to the current datamodel and xpath based expressions handling.

And this includes SCXML documents using the supported non-xpath languages like
Jexl, Ecmascript and Groovy!

These changes are needed to 'fix' the current incomplete and incorrect datamodel
handling and in particular the usage of the custom Data() function and the
<assign> action.

This issue, and the related subtasks, will take some time to process and
complete, and in the mean time the current SCXML 2.0 trunk might become
intermediately instable.

So please be warned and probably best do NOT update to the incoming changes
until the dust has settled...
Unless you'd like to hand me some help, with testing, feedback or otherwise,
which I'd definitely would appreciate!

I'll send a following heads-up to this list once I think the engine is
stabilized again and reliable enough to upgrade again.

And as indicated, this WILL result in some breaking changes in how you use the
Data() function and <assign> action.
I'll provide a comprehensive explanation and migration instructions once it is
clear what and how exactly has or will be changed.

Kind regards,

Ate


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to