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 >
