As of Spring Boot 2.4.2, with spring-data if the ES server is behind a reverse proxy with a prefix, there's no way to use Spring Boot's autoconfiguration for spring.elasticsearch.rest or spring.data.elasticsearch.client.reactive properties. One has to use the AbstractElasticsearchConfiguration in order to use the ClientConfiguration.builder().withPathPrefix(prefix). The horror.

Ideally, we could:

  • directly specify the path-prefix in the spring.elasticsearch.rest.uris property (useful in case there are multiple urls, each with its own path prefix). I don't know how that would work with spring.data.elasticsearch.client.reactive.endpoints, as it only uses a host:port format.
  • specify the path-prefix in a spring.elasticsearch.rest.path-prefix or spring.data.elasticsearch.client.reactive.path-prefix property. In that case, it would behave like the withPathPrefix(String) method, applying the prefix to all the uris/endpoints in the list

Comment From: wilkinsona

If we need a new property, we need to consider https://github.com/spring-projects/spring-boot/issues/23106.

Comment From: philwebb

We'll either add a property when we look at #23106 or we might consider adding a Customizer callback interface.

Comment From: wilkinsona

On the imperative side, the path prefix can be configured using a RestClientBuilderCustomizer bean. On the reactive side there's no equivalent customizer. For symmetry, it feels to me like we should add one regardless of whether or not we add a new path-prefix property.

Comment From: wilkinsona

directly specify the path-prefix in the spring.elasticsearch.rest.uris property (useful in case there are multiple urls, each with its own path prefix)

Elasticsearch's REST client does not appear to support this. The URIs are used to create Node or HttpHost instances, neither of which can convey a path prefix. In other words, the path prefix has to be the same across every node with which the client will communicate. Given this, I think that the only configuration property-based option that makes sense is to provide a new path-prefix property. This will work for both clients.

Comment From: TarekSaid

I think that the only configuration property-based option that makes sense is to provide a new path-prefix property

Agreed. The only reason why I proposed that first solution was because in our application-dev.yml I was pointing either to a local ES instance (without path prefix) or to a test ES instance (with path prefix), but that's too much of a niche problem (and a non-standard one at that, I've created a separate test profile with its application-test.yml since), a simple path-prefix property will work.

Comment From: AlexeiZenin

We'll either add a property when we look at #23106 or we might consider adding a Customizer callback interface.

Customizer would be great. Currently just trying to add some request interceptors to do some signing (needed for AWS Elasticsearch Service). Currently hairy to extend the AbstractReactiveElasticsearchConfiguration class and then have to call the public method of ReactiveElasticsearchRestClientAutoConfiguration to get the standard setup to still run without copy-pasting.

Comment From: wilkinsona

@AlexeiZenin Please open a separate issue for providing a customizer on the reactive side that shows your current approach. I'd like to see it to understand if a callback that is passed the TerminalClientConfigurationBuilder meets your needs.