New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate common Elasticsearch configuration properties #23106
Comments
See also #22692 |
Note for the team - during our discussion we wondered what would happen if we'd configure both properties to the correct Elasticsearch endpoint. I've tried the following configuration (note that they need different values here...): spring.elasticsearch.rest.uris=http://localhost:9201
spring.data.elasticsearch.client.reactive.endpoints=localhost:9201 The application did start correctly and Spring Data detected the repository type:
During our team call, we discussed this issue and had a few ideas in mind. We could move both spring.elasticsearch.rest.uris and spring.data.elasticsearch.client.reactive.endpoints to a new, shared property that would cover all cases: an Elasticsearch REST client (low or high level), Spring Data Repositories (imperative powered by the Elasticsearch REST client, or reactive powered by WebClient). My previous comment shows that even with a classpath containing all of Spring Data Elasticsearch, the Elasticsearch REST client and WebFlux, this would still work as expected and Spring Data would make the right choice with the repositories. Now the spring-boot-starter-data-elasticsearch brings in Spring Data Elasticsearch and the Elasticsearch REST clients. We could consider creating a different starter spring-boot-starter-data-reactive-elasticsearch that would bring WebFlux and exclude the Elasticsearch REST clients, just to split the use cases a bit more. |
The reactive client wanting host:port pairs while the imperative client wants http:// or https:// URIs that may contain a username and password too. This makes a common |
If we share a single
There's the added complication that the imperative REST client side of things also allows credentials to be provided in the URIs. When there are multiple URIs, it's possible for each to use different credentials. Using different credentials for different endpoints isn't supported by the reactive REST client so we may need to fail if multiple URIs with different credentials are configured. |
After a chat with @snicoll, we concluded that the timeout properties should be consolidated as well. At the moment, we've got the following:
Despite its name,
This is becoming and increasingly big change. The original problem has a workaround (excluding some auto-configuration) so our feeling is that we shouldn't try to squeeze this into 2.4. Instead, we'll defer this to 2.5 where it can be implemented early on and have longer to bake before release. |
hm... I don't know if it follows Spring conventions, but what about something like this:
edit: I know this should probably be in a separate issue, but it would be nice if we could have a path-prefix property (for an Elasticsearch server behind a proxy):
|
Thanks for the suggestions, @TarekSaid. For once, naming things isn't the hard part in this case. The difficulty is in how to handle the cases where there are multiple properties at the moment that we'd like to combine into one. Some of these difficulties are described in the comments above. If you're interested, the beginnings of the changes that are needed are in this branch. |
If imperative Spring Data Elasticsearch is being used and Spring Boot WebFlux starter happens to exist only for
WebClient
, the following exceptions are thrown:I can work around it by excluding auto-configurations for reactive ones:
spring.autoconfigure.exclude=\ org.springframework.boot.actuate.autoconfigure.elasticsearch.ElasticSearchReactiveHealthContributorAutoConfiguration,\ org.springframework.boot.autoconfigure.data.elasticsearch.ReactiveElasticsearchRepositoriesAutoConfiguration,\ org.springframework.boot.autoconfigure.data.elasticsearch.ReactiveElasticsearchRestClientAutoConfiguration
This is a sample project to reproduce it: https://github.com/izeye/spring-boot-throwaway-branches/tree/data-elasticsearch-and-web-client
It would be good if an option for choosing among imperative, reactive, and both was given.
The text was updated successfully, but these errors were encountered: