[
https://issues.apache.org/jira/browse/SCXML-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213323#comment-14213323
]
Ate Douma commented on SCXML-213:
---------------------------------
An important behavioral change to be aware of:
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.
> Fixing the datamodel handling - reimplement xpath processing, the Data()
> function and the <assign> action
> ---------------------------------------------------------------------------------------------------------
>
> Key: SCXML-213
> URL: https://issues.apache.org/jira/browse/SCXML-213
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> The current datamodel handling, using JAXP based xpath expressions, the
> custom Data() function and the implementation of the <assign> action is very
> limited, incomplete, and not at all SCXML spec compliant.
> JAXP based xpath expressions require a predefined datatype to be specified
> for the result, which is pretty much a blocker, as it cannot be known upfront
> by the SCXML engine what the intended datatype should be.
> As as consequence the current XPathEvaluator always converts the result of an
> normal (eval) expression to type String.
> And the result of a location expression must be a NodeSet of which only the
> first Node element is returned.
> For example an XPath variable cannot be used as assignment location, which
> this must be supported by the SCXML specification.
> The Builtin#data() method (as implementation of the Data() function) always
> needs an intermediate single Node result from the #dataNode location method,
> after which the Node its String content is *tried to* be converted to a
> Double, or else a Long, or as fallback the String value itself is returned.
> Returning a Node or even a NodeSet currently is not supported (directly),
> except by using the (private) #dataNode method to evaluate the 'expr'
> parameter for the <assign> element.
> The SCXML spec however requires much more extensive expressions, including
> using a NodeSet as value AND as target.
> The SCXML <assign> element as result currently can only deal with a too
> limited set of use-cases, not even close to what is required to be supported
> by the SCXML spec.
> To fix this properly will require some extensive (breaking) changes...
> First of all, I plan to replace the JAXP xpath expression handling with
> Commons JXPath.
> After tested and experimented with it for quite some time JXPath turns out to
> fit very nicely with the SCXML requirements.
> And the JXPath support for xpath expressions applied to 'plain' Java beans
> makes it extremely convenient to support and 'navigate' nested SCXML system
> variables like the _event.data,
> without having to 'convert' this into native DOM structures. The current JAXP
> based xpath expressions cannot deal with this at all.
> Commons JXPath also makes it possible to properly implement xpath location
> expressions, returning JXPath pointer(s) which can be used to detect AND set
> left hand expressions,
> including xpath variables (and nested Java bean paths as well).
> And JXPath also will allow redefining and reimplementing the Data() function
> for non-xpath expression languages in a more 'native' and straightforward
> way, with support for non-flattened/converted return type data.
> Furthermore JXPath can use and map the SCXML Context variables, and thus also
> the datamodel entries directly.
> The Data() function now can be properly implemented requiring *only* an xpath
> expression instead of also requiring a data node variable to operate against:
> So, instead of Data(node1, 'expr') we then can use Data('expr') where the
> node node1 itself is directly accessed within the expression.
> With these changes and enhancements the <assign> action then can be
> reimplemented to support all the specification requirements.
> To support location expressions targeting datamodel nodes or xpath variables
> for non-xpath based languages will require some extra customizations though
> to be able to access the 'pointer' of a location target.
> For this purpose probably we need a separate location expression attribute,
> e.g. xlocation="" instead of location="" to hint the SCXML engine the
> location needs to be evaluated as xpath expression returning pointers, not
> data.
> All these changes will be rather invasive and potentially breaking for
> existing SCXML documents using the Data() function and <assign> element.
> And likely this will take several steps to implement properly with a
> potentially unstable intermediate state of the SCXML engine implementation.
> I'll create separate sub tasks for these steps: the JAXP replacement with
> Commons JXPath, the Data() function and related Builtin class changes, and
> the changes to the <assign> action.
> Until all these sub tasks are completed the current SCXML trunk might thus
> become unstable and probably should *not* be used/tested for current
> projects...
> Once everything is working again as intended and this umbrella issue has been
> resolved, I'll give a heads-up on the users@ list with comprehensive
> explanations and instructions how to 'migrate' to the new implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
