Hi, I find the exposure of an implementation detail (usage of Apache HTTP client) of the Elasticsearch client a bit problematic. If they change this to another HTTP client, our SPI would break.
Did you instead consider to just let users provide their custom instance of org.elasticsearch.client.RestClient? It's still leaking an implementation detail of Hibernate Search, but at least it's one indirection less. People wishing to have a custom RestClient would have to implement a few more bits themselves (the logic from DefaultElasticsearchClientFactory#customizeHttpClientConfig()), but I'd find that acceptable for the sake of a less detail-exposing SPI, plus it grants more flexibility in terms of configuring the RestClient. --Gunnar 2017-06-01 19:11 GMT+02:00 Sanne Grinovero <sa...@hibernate.org>: > Yoann has been working on allowing Hibernate Search users to use > Elasticsearch on AWS. > > Specifically on AWS the Elasticsearch security can be configured to > use application identities, which implies the requests need to be > signed. > > A good background read can be found here [1]. > > We planned to allow people to use this but were not planning to > include AWS specific libraries as dependencies - but since Yoann > implemented an actual AWS signer in the tests I suppose it would be > selfish to not ship it.. > > Please see the API proposal on github (with the PR): > - https://github.com/hibernate/hibernate-search/pull/1426 > > Thanks, > Sanne > > [1] - > https://aws.amazon.com/blogs/security/how-to-control-access-to-your-amazon-elasticsearch-service-domain/ > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
