elasticsearch/elasticsearch-lang-groovy — Issue #1: Should rootResolveStrategy in GXContentBuilder be Closure.OWNER_FIRST?
Author: ianibo
Created: 2012-02-18 10:37:51+00:00
State: open

Hallo!

I've experienced a few difficulties using GNodeBuilder which I've tracked back to the resolver strategy used for the closure in GXContextBuilder. I was wondering if there was a specific reason for this (It's explicitly declared, but then set to the default, so I assume someone has tried alternatives in the past?). I wonder if Closure.DELEGATE_FIRST might help others avoid this issue and make the groovy api a tiny bit more usable.. Specifically:

I have a GClient constructed in a groovy scriptlet that simply refuses to join a cluster (Non default name). The code comes from a perfectly usable grails app which connects without difficulty. I wanted to create a bulk load Groovy scriptlet, so reused the connect code (https://gist.github.com/1858624) to my surprise the code that works in a grails app fails to connect to the cluster when run as a scriptlet. After some investigation I realised that the dynamic scriptlet class seems to provide some expando type functionality, and it's own version of setProperty. This means that because of the OWNER_FIRST resolver strategy, whenever nodeBuilder is used on a class supporting dynamic properties, the properties you want set on the builder will actually be set on the parent object (In this case the scriptlet). I don't think this is really what's intended, and wonder if DELEGATE_FIRST (Or even better DELEGATE_ONLY) would be more appropriate / avoid possible problems. I've recompiled my local elasticsearch-lang-groovy with the change and things seem much improved.

A workaround is to nest the connect code in a delegate class that has no meta-programming, but this one foxed me for a while, and I thought it worth at least noting, even if the resolver strategy should stay as OWNER_FIRST.

Cheers,
Ian.