It's too bad HttpSolrServer setup this client philosophy. It's momentum was directly opposite to what you want: a SolrClient that can optionally stream or load balance and a SolrCloudClient that wraps it.
[Mark Miller - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=2kigx5) [2kigx5] On April 25, 2024 at 20:07 GMT, David Smiley <dsmi...@apache.org> wrote: Our SolrJ class hierarchy is looking rather confusing right now for the HTTP ones especially. This message is mostly a big FYI, with some reflections and a recommendation or two. SolrClient - BaseHttpSolrClient (NOT yet deprecated but should be?) - - HttpSolrClient (based on Apache HttpClient; deprecated) - - - DelegationTokenHttpSolrClient - CloudSolrClient - - CloudHttp2SolrClient - - CloudLegacySolrClient (based on Apache HttpClient; deprecated) - ConcurrentUpdateHttp2SolrClient - - ... - ConcurrentUpdateSolrClient (based on Apache HttpClient; deprecated) - - ... - HttpSolrClientBase (this is new) - - Http2SolrClient - - HttpJdkSolrClient (this is new; based on the JDK HttpClient) - LBSolrClient - - LBHttp2SolrClient - - LBHttpSolrClient (based on Apache HttpClient; deprecated) In retrospect, we can see that some past names weren't so great after all. I think our clients should reflect the vendor/source of the HttpClient. "HttpJdkSolrClient" is the newest client, and it reflects the vendor (JDK provided HttpClient). Personally I don't care enough to rename all the ones with "2" in there to have "Jetty" but that's what they are -- if it has a "2", it's using Jetty (and it supports 1.1; FYI JDK also supports both 1.1 and 2 as well). The clients for Apache HttpClient are all deprecated so perhaps we continue to leave them be, mostly. Removing them will take some time; they are entrenched! BaseHttpSolrClient (the parent of HttpSolrClient) is at the moment even more confusing because HttpSolrClientBase was just added. BaseHttpSolrClient should be removed now; it only holds 2 static inner classes for RemoteSolrException and RemoteExecutionException which should find a new home somewhere. Since they are referenced so much, that will happen only in main. HttpSolrClientBase is a tempting home but SolrClient would be fine, I think. Also, just because we have a nice new HttpJdkSolrClient, doesn't mean we can yet advise anyone to safely remove Apache & Jetty dependencies *yet*! We have no tests that this works, and a quick attempt I did recently showed there are some obscure references still! Modularizing SolrJ further (for Jetty & Apache) will help reveal where we have some references, after which we can finally free users of needing those dependencies. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
