Thanks for summarizing this all David! We have HttpSolrClientBase AND BaseHttpSolrClient?!
A bit of the messiness here seems like it will resolve itself "automatically" if we make good on removing the existing deprecations. (Though given how "entrenched" the Apache client is, that will require a good bit of work...). I like the convention established by the JDK client, of naming our low-level SolrClient implementations based on the HttpClient vendor in use. IMO doing otherwise can be confusing in a few different ways. It's not high on my list to act on it immediately, but if there's enough consensus on the idea of renaming (e.g.) Http2SolrClient, I could file a ticket to document that as an ideal step and maybe it'll hook someone eventually? Best, Jason On Thu, Apr 25, 2024 at 11:34 PM Mark Miller <markrmil...@gmail.com> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
