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 <sanne(a)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-amazo...
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev