Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 29 Dec 2015 12:38:49 +0000 (UTC)
From: "Ate Douma (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12924677.1451392670000.21965.1451392729654@Atlassian.JIRA>
In-Reply-To: <JIRA.12924677.1451392670000@Atlassian.JIRA>
References: <JIRA.12924677.1451392670000@Atlassian.JIRA>
 <JIRA.12924677.1451392670154@arcas>
Subject: [jira] [Created] (SCXML-245) Reimplement Nashorn Javascript context
 binding
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Ate Douma created SCXML-245:
-------------------------------

             Summary: 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.

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.   


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)