So I did a quick experiment of:
---
a/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
+++
b/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
-
CoreGremlinPlugin.instance().getCustomizers("gremlin-groovy").ifPresent(c ->
listOfCustomizers.addAll(Arrays.asList(c)));
+
CoreGremlinPlugin.instance().getCustomizers("gremlin-groovy").ifPresent(c ->
listOfCustomizers.addAll(0, Arrays.asList(c)));
While this does allow my DSL's __ to be the one found, oddly, some other static
imports no longer appear in the interpreter; specifically 'label'.
(Referencing 'T.label' works fine.) It isn't that the symbol lookup finds the
incorrect class; I get the error "groovy.lang.MissingPropertyException: No such
property: label for class: Script2", however, some other enums (ie, 'incr') are
imported just fine.
Any ideas why that would occur?
On 2/14/18, 10:46 AM, "Stephen Mallette" <spmalle...@gmail.com> wrote:
There was a time when I looked into that in pretty grave detail. I don't
recall my findings exactly, but I obviously didn't come up with a nice
solution. I'm not sure that I ever became convinced that any of this groovy
import stuff behaves in a completely deterministic way. I suppose you could
try it out and see if that change helps or not....
On Wed, Feb 14, 2018 at 12:42 PM, Moore, Branden James <bjm...@sandia.gov>
wrote:
> Thanks for fixing issue #1. I figured that one would be easy to fix.
>
> As for issue #2, I'm wondering if changing the GremlinGroovyScriptEngine
> to add it's ImportCustomizer (line 247) to the beginning of the list of
> customizers, rather than the end, would allow DSLs (and any other imports)
> to override the default Gremlin imports.
>
> - Branden
>
> On 2/14/18, 8:23 AM, "Stephen Mallette" <spmalle...@gmail.com> wrote:
>
> Oops - the `getAnonymousTraversalClass()` should get generated
> properly. I
> created this issue:
>
> https://issues.apache.org/jira/browse/TINKERPOP-1890
>
> which i already pushed a fix for:
>
> https://github.com/apache/tinkerpop/commit/
> 2d7113aaa166b69a8503be27aebf36a8063b82bd
>
> your second problem....hmm - not sure what to do with that. Trying to
> think
> of what could be done:
>
> 1. Ugly, but you could always specify the package name......super
gross
> 2. You could statically import your anonymous steps in a custom import
> in
> Gremlin Server so instead of g.persons(__.xxx()) you would do
> g.persons(xxx()).
> 3. It would be a bit of work, but I suppose the DSL processor could be
> modified somehow to allow you to rename the DSL double underscore
> class to
> something else (triple underscore ??? hehe), then you could just
> import it.
>
> Seems like option 2 would work best in the short term.
>
>
>
>
>
> On Tue, Feb 13, 2018 at 6:50 PM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > Hi all,
> >
> > We are using the @GremlinDsl annotation to extend the Gremlin
> language
> > into our own DSL. I’ve run into two issues with anonymous
> traversals so
> > far that I’d like to bring up. One has a work-around, the other, I
> have
> > not yet found a work-around.
> >
> > First (the one with the work-around): The <DSL>TraversalSource
> class that
> > is generated does not override the ‘getAnonymousTraversalClass()’
> method of
> > GraphTraversalSource, so the returned class is
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__
> > rather than the auto-generated, DSL-specific version of ‘__’.
> This can
> > be worked around by specifying your own base class that implementes
> > ‘getAnonymousTraversalClass()’. However, this still requires some
> > oddities, as the code generator interprets the method as a method to
> be
> > auto-generated. My solution was to create two levels of
> inheritance:
> >
> > 1. MyDSLTraversalSourceDsl0 extends GraphTraversalSource, and
> > implements ‘getAnonymousTraversalClass()’
> > 2. MyDSLTraversalSourceDsl1 extends MyDSLTraversalSourceDsl0, but
> does
> > nothing else
> > 3. MyDSLTraversalDSL extends GraphTRaversal.Admin<S,E>, and uses
> the
> > @GremlinDsl(traversalSource = “MyDSLTraversalDSL1”)
> >
> >
> >
> > The second issue, for which I have not yet found a work-around, is
> that
> > when using the Gremlin-Groovy scriptEngine as a Gremlin Server, and
> sending
> > “gremlin” to the server (rather than bytecode), anonymous traversals
> do not
> > find my DSL’s implementation of __, but rather the TinkerPop __.
> I’ve
> > added my ‘__’ to the ImportGremlinPlugin’s classImports. This is
> > sufficient for sending bytecode and having my __ found. However,
> when
> > sending “gremlin” to the Session Processor, with “eval” as the OP,
> the
> > groovy class cache finds TinkerPop’s __ rather than my __. This
is
> > appears to be because in GremlinGroovyScriptEngine, the
> CoreGremlinPlugin’s
> > customizers get added last to the list of ImportCustomizers. As it
> is
> > processed last, when building the map of class names to
> fully-qualified
> > class names, the Gremlin ‘__’ key overwrites the ‘__’ key which was
> > specified to be imported in the server’s YAML. I also came across
> an
> > interesting comment in ‘ImportGroovyCustomizer’ which forces an
> import of
> > Tinkerpop’s ‘__’ as well.
> >
> > It's quite possible that I’m missing something, if so, could you
> please
> > point me to how one is supposed to enable a custom DSL with the
> > Gremlin-Groovy script engine?
> >
> > Thanks much,
> >
> > * Branden
> >
> >
>
>
>
