Sorry - those imports are really mysterious to me. I dug through a fair bit
of groovy code trying to figure out what the rules were for that import
stuff and i don't recall getting to the bottom of it.
On Wed, Feb 14, 2018 at 2:27 PM, Moore, Branden James <bjm...@sandia.gov>
wrote:
> 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
> > >
> > >
> >
> >
> >
>
>
>
