In Solr 10, SolrJ will have new maven coordinates and the need to explicitly pull in solrj-xx dependencies. So we coult also do a few key renames such as "Http2SolrClient" -> "HttpJettySolrClient", while we're busy breaking things :)
Jan > 30. apr. 2024 kl. 13:21 skrev Jason Gerlowski <gerlowsk...@gmail.com>: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
