Ate Douma created SCXML-245:
-------------------------------
Summary: Reimplement Nashorn Javascript context binding
Key: SCXML-245
URL: https://issues.apache.org/jira/browse/SCXML-245
Project: Commons SCXML
Issue Type: Improvement
Reporter: Ate Douma
Assignee: Ate Douma
Fix For: 2.0
The current Javascript context binding can be drastically improved and
simplified by using a binding which only delegates to the SCXML context it
wraps, and not (also) another binding and/or the Nashorn Global binding.
This way, all Javascript context binding changes only will end up in the SCXML
context and the Nashorn Global can remain (and should be) 'untouched'.
This is largely similar to how the Groovy context binding works.
The Nashorn Global binding will be the only 'exception' to this: the new
JSBinding will keep that one variable (with key "nashorn.global) separate, not
storing it in the SCXML context itself.
This will also simplify the SCXML context serialization (as the Nashorn Global
is NOT serializable).
Pre-requisite is that for each SCXML document+JSEvaluator only a single script
engine will be used and all script/condition evaluations are using the same
Nashorn Global. Which actually will give a performance improvement as well.
The only 'limitation' will be that Nashorn Global modifications (like
modifications made to Javscript global objects like Object) will also NOT be
stored in the SCXML context, and therefore not be serialized either.
But then, those weren't serializable to begin with, so this is an intrinsic
limitation of using the Javascript engine anyway.
Meaning: when using the Javascript engine, global modifications cannot and
won't be serialized.
However, as a single and separate engine will be used ('attached') for each
SCXML instance, and (therefore) share a single Nashorn Global, as long as the
SCXML instance doesn't need to be (de)serialized, using global modifications
should just 'work' within the context of that single SCXML instance execution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
