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