Help for plugin authors
editHelp for plugin authors
editThe Elasticsearch repository contains examples of:
- a Java plugin which contains Java code.
- a Java plugin which contains a rescore plugin.
- a Java plugin which contains a script plugin.
These examples provide the bare bones needed to get started. For more information about how to write a plugin, we recommend looking at the plugins listed in this documentation for inspiration.
Plugin Structure
editAll plugin files must be contained in a directory called elasticsearch
.
Plugin descriptor file
editAll plugins must contain a file called plugin-descriptor.properties
in the folder named elasticsearch
. The format
for this file is described in detail here:
/buildSrc/src/main/resources/plugin-descriptor.properties
.
Either fill in this template yourself or, if you are using Elasticsearch’s Gradle build system, you
can fill in the necessary values in the build.gradle
file for your plugin.
Mandatory elements for plugins
editElement | Type | Description |
---|---|---|
|
String |
simple summary of the plugin |
|
String |
plugin’s version |
|
String |
the plugin name |
|
String |
the name of the class to load, fully-qualified. |
|
String |
version of java the code is built against.
Use the system property |
|
String |
version of Elasticsearch compiled against. |
Note that only jar files in the elasticsearch directory are added to the classpath for the plugin! If you need other resources, package them into a resources jar.
Plugin release lifecycle
You will have to release a new version of the plugin for each new Elasticsearch release.
This version is checked when the plugin is loaded so Elasticsearch will refuse to start
in the presence of plugins with the incorrect elasticsearch.version
.
Testing your plugin
editWhen testing a Java plugin, it will only be auto-loaded if it is in the
plugins/
directory. Use bin/elasticsearch-plugin install file:///path/to/your/plugin
to install your plugin for testing.
You may also load your plugin within the test framework for integration tests. Read more in Changing Node Configuration.
Java Security permissions
editSome plugins may need additional security permissions. A plugin can include
the optional plugin-security.policy
file containing grant
statements for
additional permissions. Any additional permissions will be displayed to the user
with a large warning, and they will have to confirm them when installing the
plugin interactively. So if possible, it is best to avoid requesting any
spurious permissions!
If you are using the Elasticsearch Gradle build system, place this file in
src/main/plugin-metadata
and it will be applied during unit tests as well.
Keep in mind that the Java security model is stack-based, and the additional permissions will only be granted to the jars in your plugin, so you will have write proper security code around operations requiring elevated privileges. It is recommended to add a check to prevent unprivileged code (such as scripts) from gaining escalated permissions. For example:
// ES permission you should check before doPrivileged() blocks import org.elasticsearch.SpecialPermission; SecurityManager sm = System.getSecurityManager(); if (sm != null) { // unprivileged code such as scripts do not have SpecialPermission sm.checkPermission(new SpecialPermission()); } AccessController.doPrivileged( // sensitive operation );
See Secure Coding Guidelines for Java SE for more information.