[
https://issues.apache.org/jira/browse/SCXML-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated SCXML-245:
----------------------------
Description:
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.
was:
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.
> 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.
> 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)
