Mailing List Archive

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, <dsmiley@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
>

+1 @David Smiley

On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
<ichattopadhyaya@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, <dsmiley@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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

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.paul@gmail.com> wrote:

> +1 @David Smiley
>
> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
> <ichattopadhyaya@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, <dsmiley@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
>

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.smiley@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.paul@gmail.com> wrote:
>
>> +1 @David Smiley
>>
>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
>> <ichattopadhyaya@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, <dsmiley@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
>>
>

+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.smiley@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.smiley@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.paul@gmail.com> wrote:
>>
>>> +1 @David Smiley
>>>
>>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
>>> <ichattopadhyaya@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, <dsmiley@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
>>>
>>

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 <tomasflobbe@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.smiley@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.smiley@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.paul@gmail.com> wrote:
>>>> +1 @David Smiley
>>>>
>>>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
>>>> <ichattopadhyaya@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, <dsmiley@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

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.asf@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 <tomasflobbe@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.smiley@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.smiley@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.paul@gmail.com> wrote:
>>>
>>>> +1 @David Smiley
>>>>
>>>> On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
>>>> <ichattopadhyaya@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, <dsmiley@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
>>>>
>>>