ElasticSearch Head-Only Plugins

If you search for howtos on elasticsearch plugin development, you will likely find a couple of inroductions to the subject, which go on about Maven, .jar files, XML configuration, and some other details.  However, sometimes rather than a true server-side plugin, all you want to do is slap some HTML UI on top of some ES query results.  Well, it turns out that ES will happily serve any  static content that is present in its plugin/[pluginname]/_site directory.  Furthermore, it will serve the index.html file from the _site directory as the default document for the plugin url (http://esserver:9200/_plugin/[pluginname]).   This is, in fact, how plugins like the ubiquitous elasticsearch-head plugin work.  It is a front-end for ES and does not require server-side interactions.

It's debatable whether a Head-Only piece of code like should  be called a plugin, since you can easily build the same functionality entirely externally, served by your own webserver or just deployed as local files.  However, it is certainly a handy way to deploy tools, particularly because you can author your ajax calls with relative urls ( "../../someEsIndex")  , and don't need to bother with knowing the scheme/host/port of the ES server.





Comments

Post a Comment

Popular posts from this blog

Web Deployment Projects targeting x64

I am working on an ASP.NET web application which has mixed-mode C++/CLI dependencies that call out to pure unmanaged DLLs. A new requirement is a 64-bit version of the application (it runs fine on Win64 in a IIS 32-bit app pool, but since 32-bit mode is an all-or-nothing proposition, it was decided we need a true 64 bit app.) I ran into a problem getting the Visual Studio Web Deployment Project to compile my app. It seems that aspnet_compiler.exe loads all of the dependencies during compilation, and the 32 bit compiler cannot load the 64 bit images (you get a "bad image format" error.) This is true even on Win64 build machines that have the .NET Framework64 (and therefore the 64-bit aspnet_compiler.exe) After a bit of spelunking through the .wdproj, I found that a relatively simple change to the MSBUILD file shipped with the WD project will allow this to work out. It simply forces MSBUILD to use the 64 bit compiler if the $(Platform) variable is set to "x64" Here is...
Read more

Unintuitive error in msi log when DTF is misconfigured

Took me a little headscratching to figure this one out. I was getting an error from my installer with the following text: MSI (s) (A8:50) [14:27:03:446]: Product: MyProduct -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_ConfigFile_Install_Immediate, entry: CA_ConfigFile_Install_Immediate, library: C:\WINDOWS\Installer\MSI51BF.tmp The problem was not really that a DLL was missing, but that I had a typo in my <CustomAction DllEntry="xxx"> declaration. The typo caused a mismatch between the DllEntry value and the actual name of the .NET method implementing the [CustomAction].
Read more

NServiceBus distributor configuration

Technical notes from figuring out how to deploy NServiceBus in a distributed environment, beyond the simple development setups: 1. In a pub-sub scenario, distributors do not need any configuration specific to the publisher they are distributing for, or the subscribers they are distributing to. The configuration they do need is to mainly to define unique queue names for the queues that the distributor owns: NServiceBus.Distributor.dll.config: <add key="DataInputQueue" value="MyDistributorDataInputQueue" /> <add key="ControlInputQueue" value="MyDistributorControlQueue" /> <add key="ErrorQueue" value="MyEnterpriseErrorQueue@machine" /> <add key="StorageQueue" value="MyDistributorStorageQueue" /> At runtime, the subscriber contacts the distributor, sending it a subscription message that includes the publisher's address and the subscription message type. This makes the distribu...
Read more