Re: Removal of Apache HttpComponents/HttpClient for 9.0?
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 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 >: > > > +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 > 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 >> 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 wrote: >>> +1 @David Smiley On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya 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, 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 >>>
Re: Removal of Apache HttpComponents/HttpClient for 9.0?
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 : > > > +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 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 >>> 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 wrote: +1 @David Smiley On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya 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, 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
Re: Removal of Apache HttpComponents/HttpClient for 9.0?
+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 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 > 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 wrote: >> >>> +1 @David Smiley >>> >>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya >>> 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, >>> 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 >>> >>
Re: Removal of Apache HttpComponents/HttpClient for 9.0?
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 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 wrote: > >> +1 @David Smiley >> >> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya >> 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, >> 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 >> >
Re: Removal of Apache HttpComponents/HttpClient for 9.0?
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 wrote: > +1 @David Smiley > > On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya > 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, 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 >
Re: Removal of Apache HttpComponents/HttpClient for 9.0?
+1 @David Smiley On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya 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, 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Removal of Apache HttpComponents/HttpClient for 9.0?
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, 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 >
Removal of Apache HttpComponents/HttpClient for 9.0?
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
