Elasticsearch Java Client

[loicmathieu]

Prototype of an Elasticsearch Java Client.

As discussed on Zulip, it cannot work untill we move to jakarta EE or we find a workaround for the Caused by: java.lang.NoClassDefFoundError: jakarta/json/spi/JsonProvider

[loicmathieu]

@stuartwdouglas rumors said you may have an idea to workaround the issue of Javax vs Jakarta EE, if so, when you'll back from PTO, can you share some throughts ?

[m-stramel]

@loicmathieu what zulip conversation are you referring to? Any updates on this since the last comment?

[loicmathieu]

@m-stramel I open a new discussion on Zulip https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Jakarta.20JSON and well, don't expect it to be soon as the Jakarta migration will take some time.

[yrodiere]

I think there are a few things you should remove, see below.

Otherwise, this makes sense. I just checked and the client really is opensource: https://github.com/elastic/elasticsearch-java

This client probably won't work with OpenSearch, but then we can always add another extension for OpenSearch.

However, the problem remains that these clients are forward-compatible, not backward-compatible:

The Elasticsearch Java client is forward compatible; meaning that the client supports communicating with greater or equal minor versions of Elasticsearch. Elasticsearch language clients are only backwards compatible with default distributions and without guarantees made.

Source

This means that upgrading the version of the client in Quarkus will force users to upgrade their cluster...

I don't know how acceptable this is, but we will need to discuss this before this extensions leaves preview.

[loicmathieu]

@yrodiere

This client probably won't work with OpenSearch, but then we can always add another extension for OpenSearch.

This is on my todo list ;)

Elasticsearch language clients are only backwards compatible with default distributions and without guarantees made

I think the same applied to the High Level Client but was not as clearly stated as now. The Java client uses the low level rest client under the cover, as the High Level Client does. So for me it's the same caveat at the existing High Level Client.

[yrodiere]

I think the same applied to the High Level Client but was not as clearly stated as now. The Java client uses the low level rest client under the cover, as the High Level Client does. So for me it's the same caveat at the existing High Level Client.

Oh certainly, that's not new. But that was one of the reasons why the High Level client never left preview. We can't reasonably guarantee backwards compatibility or timely updates in case of CVEs if that's all the client can offer us...

I don't really have a solution, just saying this is a problem and we'll need to agree on a solution.

[loicmathieu]

I don't really have a solution, just saying this is a problem and we'll need to agree on a solution.

This is a limitation of this client and we don't have a solution. We can warn the user but again, as we don't have a solution and it's a decision we didn't take it's difficult to answer questions about it that will arise if we add some sentence warning about it in our guide.

To be honest, I used the high level rest client in multiple projects and we didn't had the issue as long as major versions are the same. I expect the same for the Java client (it is automatically build from the REST API so as long as the REST API didn't have breaking change the client will not have any).

Competitors framework already include this client and people will start asking for it, especially now that the high level client is stuck at 7.10. I know it's not a reason to offer a new extension but it's something to take into consideration. And it will allow us to remove the high level client extension after a few release cycle :).

So even if it's not a great solution, I think it's the better we can offer.

[loicmathieu]

Native build is failing, I'll have a look in the next few days.

[loicmathieu]

@zakkak the native build of this PR failed with the following error :

Error: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved method during parsing: org.elasticsearch.client.RequestOptions$Builder.setHttpAsyncResponseConsumerFactory(org.elasticsearch.client.HttpAsyncResponseConsumerFactory). This error is reported at image build time because class co.elastic.clients.transport.rest_client.RestClientOptions$Builder is registered for linking at image build time by command line

However, the method org.elasticsearch.client.RequestOptions$Builder.setHttpAsyncResponseConsumerFactory(org.elasticsearch.client.HttpAsyncResponseConsumerFactory). is present on the classpath, do you have an idea why such thing can happen and how to debug this ?

[yrodiere]

LGTM, though I added a suggestion regarding the preview status and I think a (very basic) documentation page would be necessary for the extension to get some visibility :)

And of course we'll have to wait for Guillaume to lift the Jakarta embargo :)

[yrodiere]

I didn't notice this before, but I think documentation is missing, do you think you could add a page?

It doesn't need to be extensive, even just stating what the extension is, what the entry point is (the client class), and including the configuration reference would be a start.

[loicmathieu]

I planned to add a documentation and a quickstart later on but as this PR will be on ice for some time I'll do it in the same PR.

The documentation will be on the already existing Elasticsearch guide and I'll update the section about the high level client to explain that the java one is prefered.

Most comments addressed

[gsmet]

I rebased on top of the Jakarta transformation.

[quarkus-bot]

Failing Jobs - Building d7f217b

Status	Name	Step	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✖	JVM Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 17
✔️	JVM Tests - JDK 18
✖	Native Tests - Messaging1	Build	⚠️ Check →	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 Windows #

- Failing: extensions/resteasy-reactive/rest-client-reactive/deployment 
! Skipped: extensions/keycloak-admin-client-reactive/deployment extensions/oidc-client-reactive-filter/deployment extensions/oidc-token-propagation-reactive/deployment and 19 more

📦 extensions/resteasy-reactive/rest-client-reactive/deployment

✖ io.quarkus.rest.client.reactive.stork.StorkResponseTimeLoadBalancerTest.shouldUseFasterService line 60 - More details - Source on GitHub

org.opentest4j.AssertionFailedError: 

expected: "hello, Alice"

[gsmet]

@loicmathieu I'm going to merge this one. Could you prepare some basic documentation before we release 3.0? Thanks!

[loicmathieu]

@gsmet thanks for the rebase. Sure I will prepare some documentation and quickstarts for this one.

[yrodiere]

Hey @loicmathieu, did you find the time to work on documentation? I couldn't find it.
Thanks.

[loicmathieu]

@yrodiere no, I plan to work on it this week. Don't hesitate to ping me if you didn't see the PR for it this week ;)