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

Mime
View raw message