[
https://issues.apache.org/jira/browse/SCXML-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082381#comment-15082381
]
Woonsan Ko commented on SCXML-245:
----------------------------------
Great fixes and cleanups!
I thought we might be able to make it serializable with JS evaluator (with
SCXML-233) before, but now I think you're totally right. The limitation should
be accepted to do it right without any hacky / dead-end approaches.
Thanks a lot!
Cheers,
Woonsan
> Reimplement Nashorn Javascript Evaluator
> ----------------------------------------
>
> Key: SCXML-245
> URL: https://issues.apache.org/jira/browse/SCXML-245
> Project: Commons SCXML
> Issue Type: Improvement
> Reporter: Ate Douma
> Assignee: Woonsan Ko
> 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.
> The SCXML context will be bound to the ScriptEngine.GLOBAL_SCOPE and for the
> ScriptEngine.ENGINE_SCOPE the default Nashorn binding will be used, which
> thereby will also hold and maps to the Nashorn Global itself.
> Javascript script execution can add/modify new or 'shadowed' variables into
> the Nashorn Global, these need to be copied/merged back into the SCXML
> context after execution.
> A separate ScriptContext will now be used for each JSEvaluator, to be
> shared/reused across invocations. JSEvaluator instances therefore must be and
> only can be used for a single SCXML instance (btw: like with the
> GroovyEvaluator).
> As the Nashorn Global cannot be serialized, modifications made from within
> Javascript execution to the Global objects themselves (e.g. bind extra
> properties/functions) will NOT be retained after serialization, and likewise
> creating Javascript objects and 'returning' them to (using within) the SCXML
> context will likewise NOT be serializable.
> Javscript based SCXML instance serialization therefore is limited within
> these constraints!
> To support the SCXML requirements for protected system variables, the
> Javascript Global will be initialized before first access with specific
> "init_global.js" script, loaded as classpath resource,
> which will bind these protected SCXML system properties into the Javscript
> Global state, as well as the required SCXML In() predicate function.
> Note that this uses the ECMAScript Object.bindProperties function, which is
> NOT (yet) implemented by the Mozilla Rhino engine, which thus cannot be used
> anymore, not even as optional extra dependency!
> The Javascript engine itself, as the init_global.js script resource, is now
> created statically only once and reused across all SCXML instances, which
> might give a performance improvement as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
