You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 18, 2020. It is now read-only.
It would be ideal if both the protocol and the host could be configurable with a default that way the caller could be provided with the options of choice. The "localhost" reference could probably be replaced with the elasticsearch.yaml's "http.host" value and a custom property could be set to allow for https vs http.
The workaround for me right now is to eliminate using the helper methods to create indices (since these calls use the ElasticRestClient class to perform it's functions) and strictly use the TransportClient Java API.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When installing plugins that require REST Calls with HTTPS vs HTTP the ElasticRestClient.java
class does not accomodate for such functionality.
}
It would be ideal if both the protocol and the host could be configurable with a default that way the caller could be provided with the options of choice. The "localhost" reference could probably be replaced with the elasticsearch.yaml's "http.host" value and a custom property could be set to allow for https vs http.
The workaround for me right now is to eliminate using the helper methods to create indices (since these calls use the ElasticRestClient class to perform it's functions) and strictly use the TransportClient Java API.
The text was updated successfully, but these errors were encountered: