+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 >>> >>
