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