Hi,
Just attepted to upgrade to solrj-9.x realized a few compiler errors on of
witch I have a suggestion for,
The thing that breaks is that we used to provide our own HttpClient for
communication with solr. Looked something like:
HttpClient getHttpClient() {
try {
…. lots of code setting up a HttpClient …
}
}
With all the flexibility of the HttpClient. Now this changed to the far less
cluttery;
CloudSolrClient toRet = new CloudSolrClient.Builder(zkHosts, Optional.empty())
.withInternalClientBuilder(httpClientBuilder)
.build();
With a httpClientBuilder
Http2SolrClient.Builder httpClientBuilder = new Http2SolrClient.Builder()
.withBasicAuthCredentials(username, password)
.withSSLConfig(sslConfig);
If I understood the migration path correctly. And makes my code very much
easier to read.
HOWEVER, sure it had to be a “however”, right…
The “sslConfig” feels sort of primitive a crude as its a simple java object
that takes a bunch of strings:
public SSLConfig(boolean useSsl, boolean clientAuth, String keyStore, String
keyStorePassword, String trustStore, String trustStorePassword) {
this.useSsl = useSsl;
this.clientAuth = clientAuth;
this.keyStore = keyStore;
this.keyStorePassword = keyStorePassword;
this.trustStore = trustStore;
this.trustStorePassword = trustStorePassword;
}
The issue we have is that we have fancy tooling that works with keystores and
lets users get hold of the java Keysore object directly (and truststore for
that matter) without needing to keep these things lying around on disks.
My suggestion here is to be able to construct the SslConfig object with
keystores directly like:
public SSLConfig(KeyStore keyStore, KeyStore trustStore) {
this.javaKeyStore = keyStore;
this.javaTrustStore = trustStore;
}
And make it fancy and non-breaking and all that. If I read correctly the
SslContext object is used to “hand build” the jks from disk and allowing the
user of solrj provide standard java keystores would be fantastic (at least for
us)
Kind regards,
Kalle Karlberg
