There is an umbrella issue for major SolrJ changes https://issues.apache.org/jira/browse/SOLR-15730. Some of the sub tasks are 10.0 only. Could add a rename jira there?
Jan > 30. apr. 2024 kl. 15:04 skrev Eric Pugh <ep...@opensourceconnections.com>: > > 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
