[jira] [Updated] (SCXML-245) Reimplement Nashorn Javascript context binding

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ 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)