Skip to content
This repository has been archived by the owner on Nov 18, 2022. It is now read-only.

Support for ElasticSearch v5 ? #19

Open
s101d1 opened this issue Dec 6, 2016 · 3 comments
Open

Support for ElasticSearch v5 ? #19

s101d1 opened this issue Dec 6, 2016 · 3 comments

Comments

@s101d1
Copy link

s101d1 commented Dec 6, 2016

Hi,

I'm getting error java.lang.IllegalStateException: Received message from unsupported version: [2.0.0] minimal compatible version is: [5.0.0] when making request to ElasticSearch v5.

Will there be a release for ElasticSearch v5.x support soon?

@mattflax
Copy link

I've been looking into this, and while the transport client is a fairly trivial change, the node client is not.

In addition, changes to the way ES is built are making it difficult to test in a packaged Dropwizard application:

  • there's an explicit reliance on log4j2 which can't (as far as I can see) be overridden by adding slf4j bridging.
  • the Build class in ES now reads its build information from the Manifest file. When you build a single jar for your Dropwizard app, this information is lost, and the Node client complains that it can't be read.

As I say, the changes to the Transport client are fairly trivial, and seem to work as expected. My work so far is here, if anyone is interested: https://github.com/mattflax/dropwizard-elasticsearch/tree/elasticsearch-5.0

@genthalili
Copy link

+1

@mattflax thanks for your solution!

mattflax pushed a commit to mattflax/dropwizard-elasticsearch6 that referenced this issue Mar 13, 2017
mattflax pushed a commit to mattflax/dropwizard-elasticsearch6 that referenced this issue Mar 13, 2017
@mattflax
Copy link

I've ended up disabling the NodeClient completely - Elastic reckon you should run a local coordinating node, and use the TransportClient to communicate with that. You can still use the setting at this stage, but it will throw an error.

There's currently an error from log4j2 when starting the Dropwizard application - I can't figure out a way around that which doesn't break the Elasticsearch client classes (which rely specifically on log4j2).

Do let me know if you have advice on better approaches to this issue - the approach I've ended up with feels a bit ham-fisted, so better suggestions would be appreciated!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants