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
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,
+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
auth
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
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
Solr
+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 S
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
> re
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 implementation
