Re: [SCXML] heads-up: Major SCXML 2.0 trunk refactoring incoming - breaking changes and intermediate instability to be expected!

[Ate Douma <at...@douma.nu>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org