After upgrade from ES-2.1.1 to ES-2.2.0 groovy scripting is broken

(Jürg Mumprecht) #1

trying a test-query after upgrading from ES-2.1.1 to ES-2-2-0

POST smd_*/_search { "query": { "match_all": {} }, "script_fields": { "test": { "script": { "inline": "1 + 1" }}}}
brings an error:

"root_cause": [ { "type": "illegal_argument_exception", "reason": "script_lang not supported [groovy]" } ],

while the same request to the 2.1.1 instance works as expected.

elasticsearch.yml has

script.inline: true script.indexed: true script.file: true

the logfile does not show anything unusual. the word groovy only appears in the errormessage shown above.

groovy jars location differ (I used the zip version under centos, jdk1.8.0_65):

`[elastic@localhost ~]$ find . -name 'groovy'



I tried also to store the script as file in the script directory: did not help. Disabling the java security manager also did not change anything. So: any idea what I should do?

Many thanks for help.

After 2.2 update scripts not working
(Jayme Rotsaert) #2

I think you need to override them specifically again for groovy true
script.engine.groovy.inline.update: true
script.engine.groovy.inline.mapping: true


(Myke) #3

I'm having the same issue. Unfortunately, Jayme's suggestion doesn't fix the problem. Were it simply a configuration issue, the "reason" messaging would differ, pointing out that groovy is disabled for requests of this type.

Relevant bits of my config:

script.inline: true
script.indexed: true
script.file: true

script.engine.groovy.inline: true true
script.engine.groovy.inline.update: true
script.engine.groovy.inline.mapping: true

(Jürg Mumprecht) #4

Thank you Jayme.
I changed my elasticsearch.yml; but the behaviour is still the same. No change in reported errors in logfile.

(Ivan Brusic) #5

Perhaps there is something written up here:

(Brian Keith) #6

After I updated from 2.1.1 to 2.2.0 I see this error when trying to use scripts.
{"type":"illegal_argument_exception","reason":"Unable to find on disk file script [closest_listing] using lang [groovy]"}

closest_lisitng.groovy is the script located at /etc/elasticsearch/scripts

Was working fine on 2.1.1.

Any ideas?

(Brian Keith) #7

For my case was causing the issue. I was trying to import some restricted classes.
I added:

 grant {
  permission org.elasticsearch.script.ClassPermission "*"; // allow all (disables filtering basically)

to the java.policy file and restarted elasticsearch. Scripts worked fine after that.

(Jürg Mumprecht) #8

sorry. Was much simpler: I did not check that ES has now a new dir modules and my setup did not link to it. Grovy Scripting is working now.

(Benjamin Delmas) #9

Is it the right solution? I was doing this simple tutorial with a fresh brew install then doing a few command lines, when I had the same error at this command line:

curl -XPOST "http://localhost:9200/playground/equipment/1/_update" -d '{ "script": "ctx._source.quantity += step", "params": { "step": 1 } }'

(Jason Tedor) #10

Is it the right solution? I was doing this simple tutorial with a fresh brew install

Reinstall from Homebrew again; the first version of the updated formula for Elasticsearch 2.2.0 did not install the modules folder from the distribution but it does now. I'm sorry!

(Benjamin Delmas) #11

That was quick thanks!


Can anyone tell me how to enable it for an embedded ElasticSearch?
Groovy worked without any problems in 2.1.1 ( Only "", "true" was needed in my case).

I added all the Jars from the new module directories.

My settings look like this:

Settings.settingsBuilder().put("script.file" , "true").put("script.indexed" , "true").put("script.inline" , "true"). put( "", "true"). put( "script.engine.groovy.inline.update", "true"). put( "script.engine.groovy.inline.mapping", "true")

I also tried to set a java.policy file.

I always see this error: IllegalArgumentException[script_lang not supported [groovy]

Do I have to manually load the Groovy module or something like that?

(David Baird) #13

+1 on this one. I'm running embedded in a grails app, so groovy is already on the classpath. I get a (non-fatal) stack trace when I create the node: script_lang not supported [groovy] when it encounters my .groovy file in the script dir. It used to work just fine on 1.7.x. I tried adding an inline script field using the search builder, but it fails in a similar way, claiming "script_lang not supported [groovy]". Any help would be greatly appreciated.

*** Update: I think the reason why it doesn't work is because groovy as a scripting language has been pulled out into the 'lang-groovy' plugin (see This is a problem for embedded nodes because there doesn't seem to be a way to install plugins using the NodeBuilder (see Add plugins from classpath in embedded Elasticsearch client node). I think in the short term 2.1.2 still works as it did before, so I'll be rolling back to that version for now.


With the help of one of your links I solved the problem with Groovy.

This code should work for ES 2.2 (Java 8 is needed!):

    Settings settings = Settings.settingsBuilder(). put(   "", "true") ...    
    Environment env = new Environment(settings);        

    Collection<Class<? extends Plugin>> classpathPlugins =  Collections.singletonList(GroovyPlugin.class);        
    node = new MockNode(env, Version.CURRENT, classpathPlugins );        

import java.util.Collection;
import org.elasticsearch.Version;
import org.elasticsearch.env.Environment;
import org.elasticsearch.node.Node;
import org.elasticsearch.plugins.Plugin;

public class MockNode extends Node {

    // these are kept here so a copy of this MockNode can be created, since Node does not store them
    private Version version;
    private Collection<Class<? extends Plugin>> plugins;

    public MockNode(Environment env, Version version, Collection<Class<? extends Plugin>> classpathPlugins)
        super(env, version, classpathPlugins);
        this.version = version;
        this.plugins = classpathPlugins;

    public Collection<Class<? extends Plugin>> getPlugins() {
        return plugins;

    public Version getVersion() {
        return version;


The workaround posted by @FisherKing works but it seems odd to me that there is no official and straightforward way of doing this.
Is this issue to be fixed in an upcoming release?

(system) #16