Sounds like a nice improvement suggestion. JIRA issue & PR welcome :-)
Note that you could probably just use some system properties today: https://github.com/apache/solr/blob/901e0debc381f988373a6d9c09ca47341dda05fb/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Http2SolrClient.java#L1363 ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Oct 2, 2023 at 5:32 PM Karl-Johan Karlberg < karljohan.karlb...@gmail.com> wrote: > 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
