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