Is there any way to support elastic scripts (expression and groovy) in embedded (WAR) deployment (programmatic registration)

Elastic Stack Elasticsearch
1

We embed elastic into our application (for variety of reasons) and I was wondering how to enable elastic scripting without having to deploy modules (script languages are organized as modules in directory per module with plugin-descriptor.properties in elastic distro) in external directory but rather embedding them into WAR file. I can pull required JARS into my WAR but is there any way I can register them grammatically without relying on directory structure to be picked up by elastic? Or maybe elastic has an alternative (to directories) discovery mechanism where plugin-descriptor.properties can be accessible via class path rather than file system?

I would be also interested to now if programmatic registration could be done for custom plugins we have to avoid external (to our app deployment)

If you could point me toward some examples I would greatly appreciate

Alex

2

I could not find any public API for registering plugins or any hints in the code that they could be loaded from alternative locations (like from inside WAR file using some sort of repository API which I can implement to let elastic load from my virtual directories inside of the WAR

I managed to make it work by putting all lang-expression JARS (maven build) into my WAR WEB-INF/lib and creating modules/lang-expression directory with plugin-descriptor.properties and plugin-security.policy externally

I doubt it is an approved way - i guess it can break in future

3

Has anyone discovered any way to have elastic register plugins on class path?

4

This isn't supported. If you want to run stuff in the same JVM as Elasticsearch you have to write a plugin.

5

there is no public API to allow registering modules or plugins
programatically. how would writing a plugin help me?

6

If you are running Elasticsearch embedded in your application because it is convenient building a plugin isn't going to help you. You'll just have to stop that eventually because at some point we'll break it without realizing and we aren't going to fix it because that is unsupported.

If you are running Elasticsearch embedded in your application because you are poking at internal things then you should instead write a plugin and have the plugin do that.

7

why destroy a very useful option of embedded deployment. We have quite a few applications on different release schedule owned by different groups that have a fairly small amount of rather complexly related data and embed elastic works perfect (including access control because we run it in local mode) and managing all aspects of elastic its upgrade etc. Going from that to having a shared cluster entrusted to ops team where every upgrade is a major pain because of a dozen apps that would need to be upgraded would bring everything to a screeching halt including adoption of latest elastic changes for newest actively developed application. Alternative is a dozen of unneeded elastic installation one for each application which all need to be deployed, secured, managed and upgraded. I mentioned on transport-wares decommissioning thread in github and would like to ask again PLEASE DO NOT KILL EMBEDDED DEPLOYMENT option. For many application that use elastic heavily but not really elastic-centric embedding is a very useful option

8