Please! It would be nice if someone laid out the work to be done in some tickets so folks could pick it up…. Otherwise it looks a bit daunting!
> On Apr 30, 2024, at 7:38 AM, Jan Høydahl <jan....@cominvent.com> wrote: > > 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 > _______________________ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
