commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SCXML-245) Reimplement Nashorn Javascript Evaluator
Date Sat, 02 Jan 2016 15:10:39 GMT

     [ https://issues.apache.org/jira/browse/SCXML-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ate Douma updated SCXML-245:
----------------------------
    Summary: Reimplement Nashorn Javascript Evaluator  (was: Reimplement Nashorn Javascript
context binding )

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

Mime
View raw message