[jira] [Closed] (TINKERPOP-1095) Create a custom ScriptContext

["stephen mallette (JIRA)" <ji...@apache.org>]

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

stephen mallette closed TINKERPOP-1095.
---------------------------------------
       Resolution: Won't Fix
    Fix Version/s:     (was: 3.3.0)

I've implemented this twice now in two different ways over the last few days and in the end it doesn't seem to make sense. The nature of {{ENGINE_SCOPE}} does't quite mean what I've long taken it to mean and in a sense I find the javadoc a bit misleading. It doesn't quite mean that the bindings are set to the engine for the life of the engine, because in the default implementation of {{AbstractScriptEngine}} the {{ENGINE_SCOPE}} bindings are replaced by whatever bindings are passed to the call to {{eval}} so they are effectively never used unless you call an {{eval}} overload without bindings, which we really don't do.

Ultimately it seems that the {{GLOBAL_SCOPE}} is an acceptable place for plugins to place bindings. The downside is that all plugins will compete for this space across all script engines. In the event of conflict, I imagine I'll go with some logging in gremlin server and an override where the last plugin wins essentially. Another downside is that if you declare the same plugin once for gremlin-groovy and once for gremlin-python and they both end up assigning the same global variables in the same space. Not sure if that's a problem for the developer, or if there's some things we could do better with the framework to help deal with that - made notes to myself to sort that out.

In any case, however that is implement, it doesn't seem to warrant a custom {{ScriptContext}}. No matter how I worked it, It ends up looking like "more code" without a ton of value to it.

> Create a custom ScriptContext
> -----------------------------
>
>                 Key: TINKERPOP-1095
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1095
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: groovy
>    Affects Versions: 3.1.0-incubating
>            Reporter: stephen mallette
>            Assignee: stephen mallette
>
> The current {{ScriptContext}} in use with the {{ScriptEngine}} is the {{SimpleScriptContext}}.  It doesnt' allow for additional scopes which might be useful when dealing with the {{ScriptEnginePluginAcceptor}} which allows plugins to inject "global" bindings into the a {{ScriptEngine}} instance (e.g. the "hdfs" object with the hadoop plugin).
> We currently inject this into the {{GLOBAL_SCOPE}} of the {{ScriptEngine}} which at the moment doesn't seem to conflict with anything, but I wonder if more separation is required.
> Another alternative would be to manage these types of "globals" with new methods on the {{DependencyManager}} interface.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)