I filed an issue: https://issues.apache.org/jira/browse/SOLR-15223 "Deprecate HttpSolrClient, mark httpcomponents dep as "optional" in SolrJ"
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Mar 5, 2021 at 2:45 PM Jan Høydahl <jan....@cominvent.com> wrote: > Auth tie in to core, solrJ, AdminUI and bin/solr. Currently we can only > make packages for core. Should look in to extend the package spec to > support plugging in these other parts too. > > But guess we could make Core parts of the auth plug-ins into (1st party) > packages and just leave the html and, bin/solr parts where they are. > > I vote for one package per auth type. Perhaps basic auth can remain in > core, it does not have any jar reps? > > Jan Høydahl > > 5. mar. 2021 kl. 18:59 skrev Tomás Fernández Löbbe <tomasflo...@gmail.com > >: > > > +1 David > > Oh I see; there are entanglements with Solr's authentication plugins > Maybe we should move the authentication plugins to contribs (don't know if > we'll need one or two, one for client-side and one for server-side? I > haven't looked much at the code). Plus, we are shipping with multiple > authentication options, while at most one will be used. > > > An even smaller baby step is to mark the httpclient dependency as > "optional" in the Maven pom we generate. This is a clue to consumers to > move on > > Also marking HttpSolrClient deprecated > +1 > > On Fri, Mar 5, 2021 at 8:18 AM David Smiley <david.w.smi...@gmail.com> > wrote: > >> An even smaller baby step is to mark the httpclient dependency as >> "optional" in the Maven pom we generate. This is a clue to consumers to >> move on. >> Also marking HttpSolrClient deprecated. >> >> ~ David >> >> On Fri, Mar 5, 2021 at 11:06 AM David Smiley <david.w.smi...@gmail.com> >> wrote: >> >>> Oh I see; there are entanglements with Solr's authentication plugins :-( >>> One step in this direction is to *move* it from SolrJ to solr-core. If >>> someone using SolrJ wants to pass whatever security tokens in headers, they >>> can add their own interceptors. Also, SolrJ 8 will likely work fine with >>> SolrJ 9, so if there are unforeseen problems after 9.0, we can address them >>> in 9.1 and users that are affected by whatever the problem is can still use >>> SolrJ 8 as an option. >>> >>> Maintaining two HTTP client code paths is a pain. It makes for possibly >>> duplicative work in metrics, tracing, authentication, and shear mental >>> overhead of what's going on. >>> >>> ~ David >>> >>> >>> On Wed, Oct 14, 2020 at 8:55 AM Noble Paul <noble.p...@gmail.com> wrote: >>> >>>> +1 @David Smiley >>>> >>>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya >>>> <ichattopadhy...@gmail.com> wrote: >>>> > >>>> > Maybe we need them for kerberos? I'm totally fine getting rid of >>>> kerberos support from Solr core some day, but it might not be very easy to >>>> refactor it into a package. >>>> > >>>> > On Sat, 10 Oct, 2020, 10:26 pm David Smiley, <dsmi...@apache.org> >>>> wrote: >>>> >> >>>> >> I think that historically, we are good at adding code but not good >>>> at removing code. We add new ways to do things but keep the old. Removal >>>> is more work often forgotten but doing nothing implicitly adds technical >>>> debt henceforth. >>>> >> >>>> >> With that segue... given that our latest SolrClient implementations >>>> are based on Jetty HttpClient (to support Http2 but should support 1.1?), >>>> do we need the original Apache HttpComponents/HttpClient as well? This is >>>> an honest question... maybe there are subtle reasons they are needed and I >>>> think it would be good as a project that we are clear on them. >>>> >> >>>> >> ~ David Smiley >>>> >> Apache Lucene/Solr Search Developer >>>> >> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> >>>> -- >>>> ----------------------------------------------------- >>>> Noble Paul >>>> >>>
