You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by David Eric Pugh <de...@yahoo.com.INVALID> on 2025/09/27 11:57:30 UTC
Http2SolrClient name...
Looking at Http2SolrClient after talking to David S the other day, and boy is it confusing. I thought it was the "client that speaks Http 2", not "the second Http Client that speaks 1 and 2".
We have a javadoc:* <p>Despite the name, this client supports HTTP 1.1 and 2 -- toggle with {@link
* HttpSolrClientBuilderBase#useHttp1_1(boolean)}. In retrospect, the name should have been {@code
* HttpJettySolrClient}.With Solr 10 coming up, should we have a HttpJettySolrClient that then is extended by Http2SolrClient and go ahead and deprecate Http2SolrClient?
Or, just rip the bandaid off, and deprecate Http2SolrClient in 9x, and introduce HttpJettySolrClient in 10? I'm guessing usage of Http2SolrClient out in the wild isn't yet prevalent.
Or neither...
Re: Http2SolrClient name...
Posted by Jason Gerlowski <ge...@gmail.com>.
I like those name/renaming suggestions. I do think it introduces a
bit of client-code churn for folks, but it's nothing unreasonable and
I think the clarity that the improved names add would be worth it in
the long run.
+1
On Sat, Sep 27, 2025 at 10:48 AM David Smiley <ds...@apache.org> wrote:
>
> I've been thinking exactly this thing, and here you proposed it :-). I also
> mentioned it to Jason at the hackathon.
>
> People expect to have an "HttpSolrClient" type; the recent Solr MCP was
> using it -- perhaps written in part by an LLM that knows about
> HttpSolrClient's pervasiveness. And who can blame any person or LLM for
> using such an obvious name like that. What a great name! Our issue as a
> project is the *implementation*.
>
> HTTP:
> * HttpSolrClient base type; not much if any implementation
> * HttpJettySolrClient (formerly known as Http2SolrClient)
> * HttpApacheSolrClient (formerly HttpSolrClient).
> * HttpJdkSolrClient (already named well).
>
> CLOUD:
> * CloudSolrClient base type
> * CloudJettySolrClient (from CloudHttp2SolrClient)
> * CloudApacheSolrClient (currently CloudLegacySolrClient). One could argue
> just leave it be given how soon it will be deleted
> * (no JDK variant exists yet, sadly)
>
> LB:
> (I dislike that the B is capitalized; would prefer to lowercase that)
> * LBSolrClient base type
> * LBJettySolrClient (from LBHttp2SolrClient)
> * LBApacheSolrClient (from LBHttpSolrClient)
> * (no JDK variant exists yet)
>
> CONCURRENT UPDATE
> * NO ConcurrentUpdateSolrClient base abstraction needed? Or just add it
> with nothing
> * ConcurrentUpdateApacheSolrClient (from ConcurrentUpdateSolrClient)
> * ConcurrentUpdateJettySolrClient (from ConcurrentUpdateHttp2SolrClient)
>
> Using a sequence of "git mv" operations on multiple commits, we could
> retain source control history, even though the project wouldn't build at a
> specific intermediary commit.
>
> All that would be Solr 10 only, but Solr 9 could un-deprecate
> HttpSolrClient along with documentation explaining what's happening.
>
> Of course, all of this will be quite disruptive to anyone with WIP on these
> very classes. James Dyer, I'm thinking of you.
>
> On Sat, Sep 27, 2025 at 7:57 AM David Eric Pugh <de...@yahoo.com.invalid>
> wrote:
>
> > Looking at Http2SolrClient after talking to David S the other day, and boy
> > is it confusing. I thought it was the "client that speaks Http 2", not
> > "the second Http Client that speaks 1 and 2".
> > We have a javadoc:* <p>Despite the name, this client supports HTTP 1.1 and
> > 2 -- toggle with {@link
> > * HttpSolrClientBuilderBase#useHttp1_1(boolean)}. In retrospect, the name
> > should have been {@code
> > * HttpJettySolrClient}.With Solr 10 coming up, should we have a
> > HttpJettySolrClient that then is extended by Http2SolrClient and go ahead
> > and deprecate Http2SolrClient?
> > Or, just rip the bandaid off, and deprecate Http2SolrClient in 9x, and
> > introduce HttpJettySolrClient in 10? I'm guessing usage of
> > Http2SolrClient out in the wild isn't yet prevalent.
> > Or neither...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Reviving this thread to link to what's probably the final installment of
the saga:
SOLR-17968 HttpSolrClient as new base class
https://github.com/apache/solr/pull/3829
The TL;DR approximation is: "HttpSolrClientBase becomes HttpSolrClient"
In November I gave it a shot then abandoned it due to disinterest, then a
few weeks ago an epiphany on the usefulness of it, and got it going again
with those later ideas. My last comment is a summary:
> I did a series of things, as seen in a series of commits:
>
> 1. HttpApacheSolrClient no longer extends HttpSolrClient in this PR.
Unfortunate but it'll interfere...
> 2. Rename HttpSolrClientBase to HttpSolrClient. (replacing my earlier
simple attempt at an abstract HttpSolrClient in this PR)
> 3. Rename HttpSolrClientBuilderBase.java to HttpSolrClient.BuilderBase
(inner class, now)
> 4. Renamed HttpSolrClient.builder() internal instance method to
`toBuilder(url)` to not conflict with...
> 5. Added HttpSolrClient.builder(url) static method, mostly using code
moved from CloudSolrClient, which now uses this.
It's really in great shape to be merged IMO, but a change to our important
SolrJ abstractions deserves peer review / feedback.
Perhaps it might even make 10.0, which would make for a better coherent
message to communicate in 10.0 release notes. It's just
refactoring/moving/renaming, for the most part.
>
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Note: a solrj-jetty module is appearing...
https://github.com/apache/solr/pull/3852
(what I did all day)
Re: Http2SolrClient name...
Posted by Gus Heck <gu...@gmail.com>.
The URL bit is referring to how you configure it to talk to solr. REST is a
whole other thing (REpresentational State Transfer), and not really
relevant to the java client which should communicate with whatever protocol
is most efficient/convenient/debuggable/etc
(json/javabin/xml/cbor/parameters/etc) regardless of how it's configured to
talk to solr.
On Fri, Nov 7, 2025 at 12:24 PM Aditya Parikh <ad...@gmail.com>
wrote:
> SolrRestClient?
>
> Thanks,
> Aditya
>
>
> On Fri, Nov 7, 2025 at 10:32 AM Gus Heck <gu...@gmail.com> wrote:
>
> > I don't think the "single" is needed on SingleUrlSolrClient? URL is
> > singular anyway
> >
> > On Fri, Nov 7, 2025 at 9:31 AM Jason Gerlowski <ge...@gmail.com>
> > wrote:
> >
> > > Oh, I'm surprised - I wasn't really trying to comment on the existence
> > > of a base abstraction (or not). In a way that's an independent
> > > question from whether we want to keep the "Http"-prefix around.
> > >
> > > I really liked your PR #3829, fwiw. And even if we decide that
> > > "Http-" should go away eventually, we needn't do that in this PR or
> > > even for 10.0. It may make sense to wait before acting on
> > > that...particularly if we don't have an alternative that we all love
> > > yet (which seems to be the case).
> > >
> > > ----
> > >
> > > I like "DirectSolrClient" from a naming perspective fwiw. IMO it does
> > > a good job of signaling the low-level-ness of these clients: they're
> > > "just" sending requests without any of the layered-on logic that our
> > > other clients offer.
> > >
> > > I'd also make another pitch for "SingleUrlSolrClient". David's
> > > reintroduction of "HttpSolrClient" in #3829 really highlights IMO that
> > > the one thing all of these "Http-" clients have in common is their
> > > single-URL-ness. ('getBaseUrl' is essentially the only method offered
> > > in the "base abstraction" in that PR). Yes, "requestWithBaseUrl"
> > > exists, but that's very much the "exception" rather than the normal
> > > case.
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Thu, Nov 6, 2025 at 9:32 PM David Smiley <ds...@apache.org>
> wrote:
> > > >
> > > > Those are some good names Jan. However, all clients can talk to any
> > > number
> > > > of cores/collections merely by adding its name to an overloaded
> method
> > > > (which I don't like BTW, alas), so that kind of rules out
> > CoreSolrClient.
> > > > And these clients can actually talk to whatever URL via
> > > requestWithBaseUrl.
> > > >
> > > > I think I prefer to actually take no action here in the end. They
> > don't
> > > > need a base abstraction beyond SolrClient.
> > > >
> > > >
> > > > On Thu, Nov 6, 2025 at 6:38 PM Jan Høydahl <ja...@cominvent.com>
> > > wrote:
> > > >
> > > > > CoreSolrClient - Emphasizes it works with a single core/collection,
> > > and it
> > > > > is also the core of the other clients
> > > > > DirectSolrClient - Direct endpoint access
> > > > >
> > > > > Jan
> > > > >
> > > > >
> > > > > > 6. nov. 2025 kl. 21:48 skrev David Smiley <ds...@apache.org>:
> > > > > >
> > > > > > Let's remove it. Well, I mean, not add it back :-)
> > > > > >
> > > > > > On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <
> > > gerlowskija@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >>> I'm lukewarm with "SimpleSolrClient"
> > > > > >>
> > > > > >> Fair enough - it's just there by way of example. If we agreed
> that
> > > the
> > > > > >> "Http"-prefix was worth reconsidering, I'm sure the group could
> > > arrive
> > > > > >> at *something* we like better.
> > > > > >>
> > > > > >>> I think HttpSolrClient is a fine name too,
> > > > > >>
> > > > > >> I guess that's where I'm lost. What do you like about the
> prefix?
> > > > > >> Are there benefits or things you like about it beyond the fact
> > that
> > > it
> > > > > >> has inertia?
> > > > > >>
> > > > > >> To my mind it conveys 0 bits of information. But maybe I'm
> > missing
> > > > > >> something...
> > > > > >>
> > > > > >> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <dsmiley@apache.org
> >
> > > wrote:
> > > > > >>>
> > > > > >>> I'm lukewarm with "SimpleSolrClient". I like that it conveys
> no
> > > > > >> additional
> > > > > >>> value-add like SolrCloud awareness or load-balancing. However
> > the
> > > JDK
> > > > > &
> > > > > >>> Jetty impls have some sophistication to their implementations,
> > like
> > > > > >> async.
> > > > > >>> I think HttpSolrClient is a fine name too, plus users and LLMs
> > have
> > > > > >> already
> > > > > >>> become quite aware of it ;-). I don't think it implies a lack
> of
> > > SSL
> > > > > >>> support.
> > > > > >>>
> > > > > >>> My only concern with bringing HttpSolrClient back (or adding
> > > > > >>> SimpleSolrClient) is that it doesn't _really_ need to exist as
> a
> > > base
> > > > > >>> abstraction. In my PR, it just exposes a URL getter. So what;
> > the
> > > > > >> caller
> > > > > >>> probably should have no need to call that any way. It can be
> > nice
> > > in a
> > > > > >>> test that wants to manually then use an HttpClient, but it
> could
> > > just
> > > > > as
> > > > > >>> well have gotten that URL from Jetty test infra.
> > > > > >>>
> > > > > >>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <
> > > gerlowskija@gmail.com
> > > > > >
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> I was re-reading this thread in preparation to review the PR
> > David
> > > > > >>>> mentioned above, and had an interesting thought that hadn't
> > > struck me
> > > > > >>>> on previous readings. I hate to bring in new ideas at the
> "11th
> > > > > >>>> hour", but I'd also hate to leave it unsaid in case folks
> think
> > > > > >>>> there's something there. So, with my apologies, here goes.
> > Feel
> > > free
> > > > > >>>> to ignore:
> > > > > >>>>
> > > > > >>>>> an LLM that knows about
> > > > > >>>>> HttpSolrClient's pervasiveness. And who can blame any
> person
> > > or
> > > > > >> LLM
> > > > > >>>> for
> > > > > >>>>> using such an obvious name like that. What a great name!
> > > > > >>>>
> > > > > >>>> ...
> > > > > >>>>
> > > > > >>>>> "HttpSolrClient" (a great-name)
> > > > > >>>>
> > > > > >>>> ...
> > > > > >>>>
> > > > > >>>>> the desirable class name "HttpSolrClient"
> > > > > >>>>
> > > > > >>>> HttpSolrClient is a much better name to expose to folks than
> > many
> > > of
> > > > > >>>> the current options (Http2SolrClient, HttpJdkSolrClient,
> etc.),
> > > which
> > > > > >>>> I think is mostly what David was trying to convey in those
> > quotes
> > > > > >>>> above. But is it *really* desirable in a general sense?
> > > > > >>>>
> > > > > >>>> The "Http-" prefix was (AFAICT) chosen at a time when it was
> > > necessary
> > > > > >>>> to distinguish these clients from "EmbeddedSolrServer" (which
> > > relied
> > > > > >>>> on a local SolrCore and didn't send any network traffic). But
> > 10+
> > > > > >>>> years on from that decision the "Http" signifier makes much
> less
> > > sense
> > > > > >>>> IMO.
> > > > > >>>>
> > > > > >>>> Today, the common-thread running through our "Http"
> SolrClients
> > is
> > > > > >>>> that (1) they use a single base URL and (2) don't layer on any
> > of
> > > the
> > > > > >>>> additional logic found in other implementations. At best, the
> > > "Http"
> > > > > >>>> signifier is disconnected from that commonality and does
> nothing
> > > to
> > > > > >>>> convey it. At worst, it's actively misleading: "Oh, I guess
> > > these are
> > > > > >>>> the only clients that use HTTP then", "Oh, I guess it only
> > > supports
> > > > > >>>> HTTP and not HTTPS"
> > > > > >>>>
> > > > > >>>> It'd be a bigger departure, but while we're renaming the
> clients
> > > is it
> > > > > >>>> worth considering something without the "Http" prefix
> > altogether?
> > > Say,
> > > > > >>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along
> > > those
> > > > > >>>> lines?
> > > > > >>>>
> > > > > >>>> Apologies again for bringing this up, and so late at that.
> > > > > >>>>
> > > > > >>>> Best,
> > > > > >>>>
> > > > > >>>> Jason
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <
> dsmiley@apache.org
> > >
> > > > > >> wrote:
> > > > > >>>>>
> > > > > >>>>> Some progress: https://github.com/apache/solr/pull/3829
> > > > > >>>>>
> > > > > >>>>> I think the org.apache.solr.client.solrj package should be
> used
> > > for
> > > > > >> not
> > > > > >>>>> only SolrClient (it's there now) but for HttpSolrClient (now
> > that
> > > > > >> it's
> > > > > >>>>> abstract & simple), but also CloudSolrClient. It's debatable
> > > what
> > > > > >>>> belongs
> > > > > >>>>> in "impl"; I don't love that package name TBH. But the
> classes
> > > > > >>>>> in org.apache.solr.client.solrj should be chosen
> conservatively
> > > > > >> since we
> > > > > >>>>> have a rich set of sub-packages to organize most things.
> Thus
> > > > > >> *only* the
> > > > > >>>>> most foundational things that otherwise have no obvious home
> > > belong
> > > > > >> in
> > > > > >>>>> org.apache.solr.client.solrj.
> > > > > >>>>
> > > > > >>>>
> > > ---------------------------------------------------------------------
> > > > > >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > >>>> For additional commands, e-mail: dev-help@solr.apache.org
> > > > > >>>>
> > > > > >>>>
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > >> For additional commands, e-mail: dev-help@solr.apache.org
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > https://a.co/d/b2sZLD9 (my fantasy fiction book)
> >
>
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
Re: Http2SolrClient name...
Posted by Aditya Parikh <ad...@gmail.com>.
SolrRestClient?
Thanks,
Aditya
On Fri, Nov 7, 2025 at 10:32 AM Gus Heck <gu...@gmail.com> wrote:
> I don't think the "single" is needed on SingleUrlSolrClient? URL is
> singular anyway
>
> On Fri, Nov 7, 2025 at 9:31 AM Jason Gerlowski <ge...@gmail.com>
> wrote:
>
> > Oh, I'm surprised - I wasn't really trying to comment on the existence
> > of a base abstraction (or not). In a way that's an independent
> > question from whether we want to keep the "Http"-prefix around.
> >
> > I really liked your PR #3829, fwiw. And even if we decide that
> > "Http-" should go away eventually, we needn't do that in this PR or
> > even for 10.0. It may make sense to wait before acting on
> > that...particularly if we don't have an alternative that we all love
> > yet (which seems to be the case).
> >
> > ----
> >
> > I like "DirectSolrClient" from a naming perspective fwiw. IMO it does
> > a good job of signaling the low-level-ness of these clients: they're
> > "just" sending requests without any of the layered-on logic that our
> > other clients offer.
> >
> > I'd also make another pitch for "SingleUrlSolrClient". David's
> > reintroduction of "HttpSolrClient" in #3829 really highlights IMO that
> > the one thing all of these "Http-" clients have in common is their
> > single-URL-ness. ('getBaseUrl' is essentially the only method offered
> > in the "base abstraction" in that PR). Yes, "requestWithBaseUrl"
> > exists, but that's very much the "exception" rather than the normal
> > case.
> >
> > Best,
> >
> > Jason
> >
> > On Thu, Nov 6, 2025 at 9:32 PM David Smiley <ds...@apache.org> wrote:
> > >
> > > Those are some good names Jan. However, all clients can talk to any
> > number
> > > of cores/collections merely by adding its name to an overloaded method
> > > (which I don't like BTW, alas), so that kind of rules out
> CoreSolrClient.
> > > And these clients can actually talk to whatever URL via
> > requestWithBaseUrl.
> > >
> > > I think I prefer to actually take no action here in the end. They
> don't
> > > need a base abstraction beyond SolrClient.
> > >
> > >
> > > On Thu, Nov 6, 2025 at 6:38 PM Jan Høydahl <ja...@cominvent.com>
> > wrote:
> > >
> > > > CoreSolrClient - Emphasizes it works with a single core/collection,
> > and it
> > > > is also the core of the other clients
> > > > DirectSolrClient - Direct endpoint access
> > > >
> > > > Jan
> > > >
> > > >
> > > > > 6. nov. 2025 kl. 21:48 skrev David Smiley <ds...@apache.org>:
> > > > >
> > > > > Let's remove it. Well, I mean, not add it back :-)
> > > > >
> > > > > On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <
> > gerlowskija@gmail.com>
> > > > > wrote:
> > > > >
> > > > >>> I'm lukewarm with "SimpleSolrClient"
> > > > >>
> > > > >> Fair enough - it's just there by way of example. If we agreed that
> > the
> > > > >> "Http"-prefix was worth reconsidering, I'm sure the group could
> > arrive
> > > > >> at *something* we like better.
> > > > >>
> > > > >>> I think HttpSolrClient is a fine name too,
> > > > >>
> > > > >> I guess that's where I'm lost. What do you like about the prefix?
> > > > >> Are there benefits or things you like about it beyond the fact
> that
> > it
> > > > >> has inertia?
> > > > >>
> > > > >> To my mind it conveys 0 bits of information. But maybe I'm
> missing
> > > > >> something...
> > > > >>
> > > > >> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org>
> > wrote:
> > > > >>>
> > > > >>> I'm lukewarm with "SimpleSolrClient". I like that it conveys no
> > > > >> additional
> > > > >>> value-add like SolrCloud awareness or load-balancing. However
> the
> > JDK
> > > > &
> > > > >>> Jetty impls have some sophistication to their implementations,
> like
> > > > >> async.
> > > > >>> I think HttpSolrClient is a fine name too, plus users and LLMs
> have
> > > > >> already
> > > > >>> become quite aware of it ;-). I don't think it implies a lack of
> > SSL
> > > > >>> support.
> > > > >>>
> > > > >>> My only concern with bringing HttpSolrClient back (or adding
> > > > >>> SimpleSolrClient) is that it doesn't _really_ need to exist as a
> > base
> > > > >>> abstraction. In my PR, it just exposes a URL getter. So what;
> the
> > > > >> caller
> > > > >>> probably should have no need to call that any way. It can be
> nice
> > in a
> > > > >>> test that wants to manually then use an HttpClient, but it could
> > just
> > > > as
> > > > >>> well have gotten that URL from Jetty test infra.
> > > > >>>
> > > > >>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <
> > gerlowskija@gmail.com
> > > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>>> I was re-reading this thread in preparation to review the PR
> David
> > > > >>>> mentioned above, and had an interesting thought that hadn't
> > struck me
> > > > >>>> on previous readings. I hate to bring in new ideas at the "11th
> > > > >>>> hour", but I'd also hate to leave it unsaid in case folks think
> > > > >>>> there's something there. So, with my apologies, here goes.
> Feel
> > free
> > > > >>>> to ignore:
> > > > >>>>
> > > > >>>>> an LLM that knows about
> > > > >>>>> HttpSolrClient's pervasiveness. And who can blame any person
> > or
> > > > >> LLM
> > > > >>>> for
> > > > >>>>> using such an obvious name like that. What a great name!
> > > > >>>>
> > > > >>>> ...
> > > > >>>>
> > > > >>>>> "HttpSolrClient" (a great-name)
> > > > >>>>
> > > > >>>> ...
> > > > >>>>
> > > > >>>>> the desirable class name "HttpSolrClient"
> > > > >>>>
> > > > >>>> HttpSolrClient is a much better name to expose to folks than
> many
> > of
> > > > >>>> the current options (Http2SolrClient, HttpJdkSolrClient, etc.),
> > which
> > > > >>>> I think is mostly what David was trying to convey in those
> quotes
> > > > >>>> above. But is it *really* desirable in a general sense?
> > > > >>>>
> > > > >>>> The "Http-" prefix was (AFAICT) chosen at a time when it was
> > necessary
> > > > >>>> to distinguish these clients from "EmbeddedSolrServer" (which
> > relied
> > > > >>>> on a local SolrCore and didn't send any network traffic). But
> 10+
> > > > >>>> years on from that decision the "Http" signifier makes much less
> > sense
> > > > >>>> IMO.
> > > > >>>>
> > > > >>>> Today, the common-thread running through our "Http" SolrClients
> is
> > > > >>>> that (1) they use a single base URL and (2) don't layer on any
> of
> > the
> > > > >>>> additional logic found in other implementations. At best, the
> > "Http"
> > > > >>>> signifier is disconnected from that commonality and does nothing
> > to
> > > > >>>> convey it. At worst, it's actively misleading: "Oh, I guess
> > these are
> > > > >>>> the only clients that use HTTP then", "Oh, I guess it only
> > supports
> > > > >>>> HTTP and not HTTPS"
> > > > >>>>
> > > > >>>> It'd be a bigger departure, but while we're renaming the clients
> > is it
> > > > >>>> worth considering something without the "Http" prefix
> altogether?
> > Say,
> > > > >>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along
> > those
> > > > >>>> lines?
> > > > >>>>
> > > > >>>> Apologies again for bringing this up, and so late at that.
> > > > >>>>
> > > > >>>> Best,
> > > > >>>>
> > > > >>>> Jason
> > > > >>>>
> > > > >>>>
> > > > >>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <dsmiley@apache.org
> >
> > > > >> wrote:
> > > > >>>>>
> > > > >>>>> Some progress: https://github.com/apache/solr/pull/3829
> > > > >>>>>
> > > > >>>>> I think the org.apache.solr.client.solrj package should be used
> > for
> > > > >> not
> > > > >>>>> only SolrClient (it's there now) but for HttpSolrClient (now
> that
> > > > >> it's
> > > > >>>>> abstract & simple), but also CloudSolrClient. It's debatable
> > what
> > > > >>>> belongs
> > > > >>>>> in "impl"; I don't love that package name TBH. But the classes
> > > > >>>>> in org.apache.solr.client.solrj should be chosen conservatively
> > > > >> since we
> > > > >>>>> have a rich set of sub-packages to organize most things. Thus
> > > > >> *only* the
> > > > >>>>> most foundational things that otherwise have no obvious home
> > belong
> > > > >> in
> > > > >>>>> org.apache.solr.client.solrj.
> > > > >>>>
> > > > >>>>
> > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > >>>> For additional commands, e-mail: dev-help@solr.apache.org
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > >> For additional commands, e-mail: dev-help@solr.apache.org
> > > > >>
> > > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>
Re: Http2SolrClient name...
Posted by Gus Heck <gu...@gmail.com>.
I don't think the "single" is needed on SingleUrlSolrClient? URL is
singular anyway
On Fri, Nov 7, 2025 at 9:31 AM Jason Gerlowski <ge...@gmail.com>
wrote:
> Oh, I'm surprised - I wasn't really trying to comment on the existence
> of a base abstraction (or not). In a way that's an independent
> question from whether we want to keep the "Http"-prefix around.
>
> I really liked your PR #3829, fwiw. And even if we decide that
> "Http-" should go away eventually, we needn't do that in this PR or
> even for 10.0. It may make sense to wait before acting on
> that...particularly if we don't have an alternative that we all love
> yet (which seems to be the case).
>
> ----
>
> I like "DirectSolrClient" from a naming perspective fwiw. IMO it does
> a good job of signaling the low-level-ness of these clients: they're
> "just" sending requests without any of the layered-on logic that our
> other clients offer.
>
> I'd also make another pitch for "SingleUrlSolrClient". David's
> reintroduction of "HttpSolrClient" in #3829 really highlights IMO that
> the one thing all of these "Http-" clients have in common is their
> single-URL-ness. ('getBaseUrl' is essentially the only method offered
> in the "base abstraction" in that PR). Yes, "requestWithBaseUrl"
> exists, but that's very much the "exception" rather than the normal
> case.
>
> Best,
>
> Jason
>
> On Thu, Nov 6, 2025 at 9:32 PM David Smiley <ds...@apache.org> wrote:
> >
> > Those are some good names Jan. However, all clients can talk to any
> number
> > of cores/collections merely by adding its name to an overloaded method
> > (which I don't like BTW, alas), so that kind of rules out CoreSolrClient.
> > And these clients can actually talk to whatever URL via
> requestWithBaseUrl.
> >
> > I think I prefer to actually take no action here in the end. They don't
> > need a base abstraction beyond SolrClient.
> >
> >
> > On Thu, Nov 6, 2025 at 6:38 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> > > CoreSolrClient - Emphasizes it works with a single core/collection,
> and it
> > > is also the core of the other clients
> > > DirectSolrClient - Direct endpoint access
> > >
> > > Jan
> > >
> > >
> > > > 6. nov. 2025 kl. 21:48 skrev David Smiley <ds...@apache.org>:
> > > >
> > > > Let's remove it. Well, I mean, not add it back :-)
> > > >
> > > > On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <
> gerlowskija@gmail.com>
> > > > wrote:
> > > >
> > > >>> I'm lukewarm with "SimpleSolrClient"
> > > >>
> > > >> Fair enough - it's just there by way of example. If we agreed that
> the
> > > >> "Http"-prefix was worth reconsidering, I'm sure the group could
> arrive
> > > >> at *something* we like better.
> > > >>
> > > >>> I think HttpSolrClient is a fine name too,
> > > >>
> > > >> I guess that's where I'm lost. What do you like about the prefix?
> > > >> Are there benefits or things you like about it beyond the fact that
> it
> > > >> has inertia?
> > > >>
> > > >> To my mind it conveys 0 bits of information. But maybe I'm missing
> > > >> something...
> > > >>
> > > >> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org>
> wrote:
> > > >>>
> > > >>> I'm lukewarm with "SimpleSolrClient". I like that it conveys no
> > > >> additional
> > > >>> value-add like SolrCloud awareness or load-balancing. However the
> JDK
> > > &
> > > >>> Jetty impls have some sophistication to their implementations, like
> > > >> async.
> > > >>> I think HttpSolrClient is a fine name too, plus users and LLMs have
> > > >> already
> > > >>> become quite aware of it ;-). I don't think it implies a lack of
> SSL
> > > >>> support.
> > > >>>
> > > >>> My only concern with bringing HttpSolrClient back (or adding
> > > >>> SimpleSolrClient) is that it doesn't _really_ need to exist as a
> base
> > > >>> abstraction. In my PR, it just exposes a URL getter. So what; the
> > > >> caller
> > > >>> probably should have no need to call that any way. It can be nice
> in a
> > > >>> test that wants to manually then use an HttpClient, but it could
> just
> > > as
> > > >>> well have gotten that URL from Jetty test infra.
> > > >>>
> > > >>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <
> gerlowskija@gmail.com
> > > >
> > > >>> wrote:
> > > >>>
> > > >>>> I was re-reading this thread in preparation to review the PR David
> > > >>>> mentioned above, and had an interesting thought that hadn't
> struck me
> > > >>>> on previous readings. I hate to bring in new ideas at the "11th
> > > >>>> hour", but I'd also hate to leave it unsaid in case folks think
> > > >>>> there's something there. So, with my apologies, here goes. Feel
> free
> > > >>>> to ignore:
> > > >>>>
> > > >>>>> an LLM that knows about
> > > >>>>> HttpSolrClient's pervasiveness. And who can blame any person
> or
> > > >> LLM
> > > >>>> for
> > > >>>>> using such an obvious name like that. What a great name!
> > > >>>>
> > > >>>> ...
> > > >>>>
> > > >>>>> "HttpSolrClient" (a great-name)
> > > >>>>
> > > >>>> ...
> > > >>>>
> > > >>>>> the desirable class name "HttpSolrClient"
> > > >>>>
> > > >>>> HttpSolrClient is a much better name to expose to folks than many
> of
> > > >>>> the current options (Http2SolrClient, HttpJdkSolrClient, etc.),
> which
> > > >>>> I think is mostly what David was trying to convey in those quotes
> > > >>>> above. But is it *really* desirable in a general sense?
> > > >>>>
> > > >>>> The "Http-" prefix was (AFAICT) chosen at a time when it was
> necessary
> > > >>>> to distinguish these clients from "EmbeddedSolrServer" (which
> relied
> > > >>>> on a local SolrCore and didn't send any network traffic). But 10+
> > > >>>> years on from that decision the "Http" signifier makes much less
> sense
> > > >>>> IMO.
> > > >>>>
> > > >>>> Today, the common-thread running through our "Http" SolrClients is
> > > >>>> that (1) they use a single base URL and (2) don't layer on any of
> the
> > > >>>> additional logic found in other implementations. At best, the
> "Http"
> > > >>>> signifier is disconnected from that commonality and does nothing
> to
> > > >>>> convey it. At worst, it's actively misleading: "Oh, I guess
> these are
> > > >>>> the only clients that use HTTP then", "Oh, I guess it only
> supports
> > > >>>> HTTP and not HTTPS"
> > > >>>>
> > > >>>> It'd be a bigger departure, but while we're renaming the clients
> is it
> > > >>>> worth considering something without the "Http" prefix altogether?
> Say,
> > > >>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along
> those
> > > >>>> lines?
> > > >>>>
> > > >>>> Apologies again for bringing this up, and so late at that.
> > > >>>>
> > > >>>> Best,
> > > >>>>
> > > >>>> Jason
> > > >>>>
> > > >>>>
> > > >>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org>
> > > >> wrote:
> > > >>>>>
> > > >>>>> Some progress: https://github.com/apache/solr/pull/3829
> > > >>>>>
> > > >>>>> I think the org.apache.solr.client.solrj package should be used
> for
> > > >> not
> > > >>>>> only SolrClient (it's there now) but for HttpSolrClient (now that
> > > >> it's
> > > >>>>> abstract & simple), but also CloudSolrClient. It's debatable
> what
> > > >>>> belongs
> > > >>>>> in "impl"; I don't love that package name TBH. But the classes
> > > >>>>> in org.apache.solr.client.solrj should be chosen conservatively
> > > >> since we
> > > >>>>> have a rich set of sub-packages to organize most things. Thus
> > > >> *only* the
> > > >>>>> most foundational things that otherwise have no obvious home
> belong
> > > >> in
> > > >>>>> org.apache.solr.client.solrj.
> > > >>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > >>>> For additional commands, e-mail: dev-help@solr.apache.org
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > >> For additional commands, e-mail: dev-help@solr.apache.org
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
Re: Http2SolrClient name...
Posted by Jason Gerlowski <ge...@gmail.com>.
Oh, I'm surprised - I wasn't really trying to comment on the existence
of a base abstraction (or not). In a way that's an independent
question from whether we want to keep the "Http"-prefix around.
I really liked your PR #3829, fwiw. And even if we decide that
"Http-" should go away eventually, we needn't do that in this PR or
even for 10.0. It may make sense to wait before acting on
that...particularly if we don't have an alternative that we all love
yet (which seems to be the case).
----
I like "DirectSolrClient" from a naming perspective fwiw. IMO it does
a good job of signaling the low-level-ness of these clients: they're
"just" sending requests without any of the layered-on logic that our
other clients offer.
I'd also make another pitch for "SingleUrlSolrClient". David's
reintroduction of "HttpSolrClient" in #3829 really highlights IMO that
the one thing all of these "Http-" clients have in common is their
single-URL-ness. ('getBaseUrl' is essentially the only method offered
in the "base abstraction" in that PR). Yes, "requestWithBaseUrl"
exists, but that's very much the "exception" rather than the normal
case.
Best,
Jason
On Thu, Nov 6, 2025 at 9:32 PM David Smiley <ds...@apache.org> wrote:
>
> Those are some good names Jan. However, all clients can talk to any number
> of cores/collections merely by adding its name to an overloaded method
> (which I don't like BTW, alas), so that kind of rules out CoreSolrClient.
> And these clients can actually talk to whatever URL via requestWithBaseUrl.
>
> I think I prefer to actually take no action here in the end. They don't
> need a base abstraction beyond SolrClient.
>
>
> On Thu, Nov 6, 2025 at 6:38 PM Jan Høydahl <ja...@cominvent.com> wrote:
>
> > CoreSolrClient - Emphasizes it works with a single core/collection, and it
> > is also the core of the other clients
> > DirectSolrClient - Direct endpoint access
> >
> > Jan
> >
> >
> > > 6. nov. 2025 kl. 21:48 skrev David Smiley <ds...@apache.org>:
> > >
> > > Let's remove it. Well, I mean, not add it back :-)
> > >
> > > On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <ge...@gmail.com>
> > > wrote:
> > >
> > >>> I'm lukewarm with "SimpleSolrClient"
> > >>
> > >> Fair enough - it's just there by way of example. If we agreed that the
> > >> "Http"-prefix was worth reconsidering, I'm sure the group could arrive
> > >> at *something* we like better.
> > >>
> > >>> I think HttpSolrClient is a fine name too,
> > >>
> > >> I guess that's where I'm lost. What do you like about the prefix?
> > >> Are there benefits or things you like about it beyond the fact that it
> > >> has inertia?
> > >>
> > >> To my mind it conveys 0 bits of information. But maybe I'm missing
> > >> something...
> > >>
> > >> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org> wrote:
> > >>>
> > >>> I'm lukewarm with "SimpleSolrClient". I like that it conveys no
> > >> additional
> > >>> value-add like SolrCloud awareness or load-balancing. However the JDK
> > &
> > >>> Jetty impls have some sophistication to their implementations, like
> > >> async.
> > >>> I think HttpSolrClient is a fine name too, plus users and LLMs have
> > >> already
> > >>> become quite aware of it ;-). I don't think it implies a lack of SSL
> > >>> support.
> > >>>
> > >>> My only concern with bringing HttpSolrClient back (or adding
> > >>> SimpleSolrClient) is that it doesn't _really_ need to exist as a base
> > >>> abstraction. In my PR, it just exposes a URL getter. So what; the
> > >> caller
> > >>> probably should have no need to call that any way. It can be nice in a
> > >>> test that wants to manually then use an HttpClient, but it could just
> > as
> > >>> well have gotten that URL from Jetty test infra.
> > >>>
> > >>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <gerlowskija@gmail.com
> > >
> > >>> wrote:
> > >>>
> > >>>> I was re-reading this thread in preparation to review the PR David
> > >>>> mentioned above, and had an interesting thought that hadn't struck me
> > >>>> on previous readings. I hate to bring in new ideas at the "11th
> > >>>> hour", but I'd also hate to leave it unsaid in case folks think
> > >>>> there's something there. So, with my apologies, here goes. Feel free
> > >>>> to ignore:
> > >>>>
> > >>>>> an LLM that knows about
> > >>>>> HttpSolrClient's pervasiveness. And who can blame any person or
> > >> LLM
> > >>>> for
> > >>>>> using such an obvious name like that. What a great name!
> > >>>>
> > >>>> ...
> > >>>>
> > >>>>> "HttpSolrClient" (a great-name)
> > >>>>
> > >>>> ...
> > >>>>
> > >>>>> the desirable class name "HttpSolrClient"
> > >>>>
> > >>>> HttpSolrClient is a much better name to expose to folks than many of
> > >>>> the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
> > >>>> I think is mostly what David was trying to convey in those quotes
> > >>>> above. But is it *really* desirable in a general sense?
> > >>>>
> > >>>> The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
> > >>>> to distinguish these clients from "EmbeddedSolrServer" (which relied
> > >>>> on a local SolrCore and didn't send any network traffic). But 10+
> > >>>> years on from that decision the "Http" signifier makes much less sense
> > >>>> IMO.
> > >>>>
> > >>>> Today, the common-thread running through our "Http" SolrClients is
> > >>>> that (1) they use a single base URL and (2) don't layer on any of the
> > >>>> additional logic found in other implementations. At best, the "Http"
> > >>>> signifier is disconnected from that commonality and does nothing to
> > >>>> convey it. At worst, it's actively misleading: "Oh, I guess these are
> > >>>> the only clients that use HTTP then", "Oh, I guess it only supports
> > >>>> HTTP and not HTTPS"
> > >>>>
> > >>>> It'd be a bigger departure, but while we're renaming the clients is it
> > >>>> worth considering something without the "Http" prefix altogether? Say,
> > >>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along those
> > >>>> lines?
> > >>>>
> > >>>> Apologies again for bringing this up, and so late at that.
> > >>>>
> > >>>> Best,
> > >>>>
> > >>>> Jason
> > >>>>
> > >>>>
> > >>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org>
> > >> wrote:
> > >>>>>
> > >>>>> Some progress: https://github.com/apache/solr/pull/3829
> > >>>>>
> > >>>>> I think the org.apache.solr.client.solrj package should be used for
> > >> not
> > >>>>> only SolrClient (it's there now) but for HttpSolrClient (now that
> > >> it's
> > >>>>> abstract & simple), but also CloudSolrClient. It's debatable what
> > >>>> belongs
> > >>>>> in "impl"; I don't love that package name TBH. But the classes
> > >>>>> in org.apache.solr.client.solrj should be chosen conservatively
> > >> since we
> > >>>>> have a rich set of sub-packages to organize most things. Thus
> > >> *only* the
> > >>>>> most foundational things that otherwise have no obvious home belong
> > >> in
> > >>>>> org.apache.solr.client.solrj.
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >>>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>>
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >> For additional commands, e-mail: dev-help@solr.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Those are some good names Jan. However, all clients can talk to any number
of cores/collections merely by adding its name to an overloaded method
(which I don't like BTW, alas), so that kind of rules out CoreSolrClient.
And these clients can actually talk to whatever URL via requestWithBaseUrl.
I think I prefer to actually take no action here in the end. They don't
need a base abstraction beyond SolrClient.
On Thu, Nov 6, 2025 at 6:38 PM Jan Høydahl <ja...@cominvent.com> wrote:
> CoreSolrClient - Emphasizes it works with a single core/collection, and it
> is also the core of the other clients
> DirectSolrClient - Direct endpoint access
>
> Jan
>
>
> > 6. nov. 2025 kl. 21:48 skrev David Smiley <ds...@apache.org>:
> >
> > Let's remove it. Well, I mean, not add it back :-)
> >
> > On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <ge...@gmail.com>
> > wrote:
> >
> >>> I'm lukewarm with "SimpleSolrClient"
> >>
> >> Fair enough - it's just there by way of example. If we agreed that the
> >> "Http"-prefix was worth reconsidering, I'm sure the group could arrive
> >> at *something* we like better.
> >>
> >>> I think HttpSolrClient is a fine name too,
> >>
> >> I guess that's where I'm lost. What do you like about the prefix?
> >> Are there benefits or things you like about it beyond the fact that it
> >> has inertia?
> >>
> >> To my mind it conveys 0 bits of information. But maybe I'm missing
> >> something...
> >>
> >> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org> wrote:
> >>>
> >>> I'm lukewarm with "SimpleSolrClient". I like that it conveys no
> >> additional
> >>> value-add like SolrCloud awareness or load-balancing. However the JDK
> &
> >>> Jetty impls have some sophistication to their implementations, like
> >> async.
> >>> I think HttpSolrClient is a fine name too, plus users and LLMs have
> >> already
> >>> become quite aware of it ;-). I don't think it implies a lack of SSL
> >>> support.
> >>>
> >>> My only concern with bringing HttpSolrClient back (or adding
> >>> SimpleSolrClient) is that it doesn't _really_ need to exist as a base
> >>> abstraction. In my PR, it just exposes a URL getter. So what; the
> >> caller
> >>> probably should have no need to call that any way. It can be nice in a
> >>> test that wants to manually then use an HttpClient, but it could just
> as
> >>> well have gotten that URL from Jetty test infra.
> >>>
> >>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <gerlowskija@gmail.com
> >
> >>> wrote:
> >>>
> >>>> I was re-reading this thread in preparation to review the PR David
> >>>> mentioned above, and had an interesting thought that hadn't struck me
> >>>> on previous readings. I hate to bring in new ideas at the "11th
> >>>> hour", but I'd also hate to leave it unsaid in case folks think
> >>>> there's something there. So, with my apologies, here goes. Feel free
> >>>> to ignore:
> >>>>
> >>>>> an LLM that knows about
> >>>>> HttpSolrClient's pervasiveness. And who can blame any person or
> >> LLM
> >>>> for
> >>>>> using such an obvious name like that. What a great name!
> >>>>
> >>>> ...
> >>>>
> >>>>> "HttpSolrClient" (a great-name)
> >>>>
> >>>> ...
> >>>>
> >>>>> the desirable class name "HttpSolrClient"
> >>>>
> >>>> HttpSolrClient is a much better name to expose to folks than many of
> >>>> the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
> >>>> I think is mostly what David was trying to convey in those quotes
> >>>> above. But is it *really* desirable in a general sense?
> >>>>
> >>>> The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
> >>>> to distinguish these clients from "EmbeddedSolrServer" (which relied
> >>>> on a local SolrCore and didn't send any network traffic). But 10+
> >>>> years on from that decision the "Http" signifier makes much less sense
> >>>> IMO.
> >>>>
> >>>> Today, the common-thread running through our "Http" SolrClients is
> >>>> that (1) they use a single base URL and (2) don't layer on any of the
> >>>> additional logic found in other implementations. At best, the "Http"
> >>>> signifier is disconnected from that commonality and does nothing to
> >>>> convey it. At worst, it's actively misleading: "Oh, I guess these are
> >>>> the only clients that use HTTP then", "Oh, I guess it only supports
> >>>> HTTP and not HTTPS"
> >>>>
> >>>> It'd be a bigger departure, but while we're renaming the clients is it
> >>>> worth considering something without the "Http" prefix altogether? Say,
> >>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along those
> >>>> lines?
> >>>>
> >>>> Apologies again for bringing this up, and so late at that.
> >>>>
> >>>> Best,
> >>>>
> >>>> Jason
> >>>>
> >>>>
> >>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org>
> >> wrote:
> >>>>>
> >>>>> Some progress: https://github.com/apache/solr/pull/3829
> >>>>>
> >>>>> I think the org.apache.solr.client.solrj package should be used for
> >> not
> >>>>> only SolrClient (it's there now) but for HttpSolrClient (now that
> >> it's
> >>>>> abstract & simple), but also CloudSolrClient. It's debatable what
> >>>> belongs
> >>>>> in "impl"; I don't love that package name TBH. But the classes
> >>>>> in org.apache.solr.client.solrj should be chosen conservatively
> >> since we
> >>>>> have a rich set of sub-packages to organize most things. Thus
> >> *only* the
> >>>>> most foundational things that otherwise have no obvious home belong
> >> in
> >>>>> org.apache.solr.client.solrj.
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Http2SolrClient name...
Posted by Jan Høydahl <ja...@cominvent.com>.
CoreSolrClient - Emphasizes it works with a single core/collection, and it is also the core of the other clients
DirectSolrClient - Direct endpoint access
Jan
> 6. nov. 2025 kl. 21:48 skrev David Smiley <ds...@apache.org>:
>
> Let's remove it. Well, I mean, not add it back :-)
>
> On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <ge...@gmail.com>
> wrote:
>
>>> I'm lukewarm with "SimpleSolrClient"
>>
>> Fair enough - it's just there by way of example. If we agreed that the
>> "Http"-prefix was worth reconsidering, I'm sure the group could arrive
>> at *something* we like better.
>>
>>> I think HttpSolrClient is a fine name too,
>>
>> I guess that's where I'm lost. What do you like about the prefix?
>> Are there benefits or things you like about it beyond the fact that it
>> has inertia?
>>
>> To my mind it conveys 0 bits of information. But maybe I'm missing
>> something...
>>
>> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org> wrote:
>>>
>>> I'm lukewarm with "SimpleSolrClient". I like that it conveys no
>> additional
>>> value-add like SolrCloud awareness or load-balancing. However the JDK &
>>> Jetty impls have some sophistication to their implementations, like
>> async.
>>> I think HttpSolrClient is a fine name too, plus users and LLMs have
>> already
>>> become quite aware of it ;-). I don't think it implies a lack of SSL
>>> support.
>>>
>>> My only concern with bringing HttpSolrClient back (or adding
>>> SimpleSolrClient) is that it doesn't _really_ need to exist as a base
>>> abstraction. In my PR, it just exposes a URL getter. So what; the
>> caller
>>> probably should have no need to call that any way. It can be nice in a
>>> test that wants to manually then use an HttpClient, but it could just as
>>> well have gotten that URL from Jetty test infra.
>>>
>>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <ge...@gmail.com>
>>> wrote:
>>>
>>>> I was re-reading this thread in preparation to review the PR David
>>>> mentioned above, and had an interesting thought that hadn't struck me
>>>> on previous readings. I hate to bring in new ideas at the "11th
>>>> hour", but I'd also hate to leave it unsaid in case folks think
>>>> there's something there. So, with my apologies, here goes. Feel free
>>>> to ignore:
>>>>
>>>>> an LLM that knows about
>>>>> HttpSolrClient's pervasiveness. And who can blame any person or
>> LLM
>>>> for
>>>>> using such an obvious name like that. What a great name!
>>>>
>>>> ...
>>>>
>>>>> "HttpSolrClient" (a great-name)
>>>>
>>>> ...
>>>>
>>>>> the desirable class name "HttpSolrClient"
>>>>
>>>> HttpSolrClient is a much better name to expose to folks than many of
>>>> the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
>>>> I think is mostly what David was trying to convey in those quotes
>>>> above. But is it *really* desirable in a general sense?
>>>>
>>>> The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
>>>> to distinguish these clients from "EmbeddedSolrServer" (which relied
>>>> on a local SolrCore and didn't send any network traffic). But 10+
>>>> years on from that decision the "Http" signifier makes much less sense
>>>> IMO.
>>>>
>>>> Today, the common-thread running through our "Http" SolrClients is
>>>> that (1) they use a single base URL and (2) don't layer on any of the
>>>> additional logic found in other implementations. At best, the "Http"
>>>> signifier is disconnected from that commonality and does nothing to
>>>> convey it. At worst, it's actively misleading: "Oh, I guess these are
>>>> the only clients that use HTTP then", "Oh, I guess it only supports
>>>> HTTP and not HTTPS"
>>>>
>>>> It'd be a bigger departure, but while we're renaming the clients is it
>>>> worth considering something without the "Http" prefix altogether? Say,
>>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along those
>>>> lines?
>>>>
>>>> Apologies again for bringing this up, and so late at that.
>>>>
>>>> Best,
>>>>
>>>> Jason
>>>>
>>>>
>>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org>
>> wrote:
>>>>>
>>>>> Some progress: https://github.com/apache/solr/pull/3829
>>>>>
>>>>> I think the org.apache.solr.client.solrj package should be used for
>> not
>>>>> only SolrClient (it's there now) but for HttpSolrClient (now that
>> it's
>>>>> abstract & simple), but also CloudSolrClient. It's debatable what
>>>> belongs
>>>>> in "impl"; I don't love that package name TBH. But the classes
>>>>> in org.apache.solr.client.solrj should be chosen conservatively
>> since we
>>>>> have a rich set of sub-packages to organize most things. Thus
>> *only* the
>>>>> most foundational things that otherwise have no obvious home belong
>> in
>>>>> org.apache.solr.client.solrj.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Let's remove it. Well, I mean, not add it back :-)
On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <ge...@gmail.com>
wrote:
> > I'm lukewarm with "SimpleSolrClient"
>
> Fair enough - it's just there by way of example. If we agreed that the
> "Http"-prefix was worth reconsidering, I'm sure the group could arrive
> at *something* we like better.
>
> > I think HttpSolrClient is a fine name too,
>
> I guess that's where I'm lost. What do you like about the prefix?
> Are there benefits or things you like about it beyond the fact that it
> has inertia?
>
> To my mind it conveys 0 bits of information. But maybe I'm missing
> something...
>
> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org> wrote:
> >
> > I'm lukewarm with "SimpleSolrClient". I like that it conveys no
> additional
> > value-add like SolrCloud awareness or load-balancing. However the JDK &
> > Jetty impls have some sophistication to their implementations, like
> async.
> > I think HttpSolrClient is a fine name too, plus users and LLMs have
> already
> > become quite aware of it ;-). I don't think it implies a lack of SSL
> > support.
> >
> > My only concern with bringing HttpSolrClient back (or adding
> > SimpleSolrClient) is that it doesn't _really_ need to exist as a base
> > abstraction. In my PR, it just exposes a URL getter. So what; the
> caller
> > probably should have no need to call that any way. It can be nice in a
> > test that wants to manually then use an HttpClient, but it could just as
> > well have gotten that URL from Jetty test infra.
> >
> > On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <ge...@gmail.com>
> > wrote:
> >
> > > I was re-reading this thread in preparation to review the PR David
> > > mentioned above, and had an interesting thought that hadn't struck me
> > > on previous readings. I hate to bring in new ideas at the "11th
> > > hour", but I'd also hate to leave it unsaid in case folks think
> > > there's something there. So, with my apologies, here goes. Feel free
> > > to ignore:
> > >
> > > > an LLM that knows about
> > > > HttpSolrClient's pervasiveness. And who can blame any person or
> LLM
> > > for
> > > > using such an obvious name like that. What a great name!
> > >
> > > ...
> > >
> > > > "HttpSolrClient" (a great-name)
> > >
> > > ...
> > >
> > > > the desirable class name "HttpSolrClient"
> > >
> > > HttpSolrClient is a much better name to expose to folks than many of
> > > the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
> > > I think is mostly what David was trying to convey in those quotes
> > > above. But is it *really* desirable in a general sense?
> > >
> > > The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
> > > to distinguish these clients from "EmbeddedSolrServer" (which relied
> > > on a local SolrCore and didn't send any network traffic). But 10+
> > > years on from that decision the "Http" signifier makes much less sense
> > > IMO.
> > >
> > > Today, the common-thread running through our "Http" SolrClients is
> > > that (1) they use a single base URL and (2) don't layer on any of the
> > > additional logic found in other implementations. At best, the "Http"
> > > signifier is disconnected from that commonality and does nothing to
> > > convey it. At worst, it's actively misleading: "Oh, I guess these are
> > > the only clients that use HTTP then", "Oh, I guess it only supports
> > > HTTP and not HTTPS"
> > >
> > > It'd be a bigger departure, but while we're renaming the clients is it
> > > worth considering something without the "Http" prefix altogether? Say,
> > > "SingleUrlSolrClient" or "SimpleSolrClient" or something along those
> > > lines?
> > >
> > > Apologies again for bringing this up, and so late at that.
> > >
> > > Best,
> > >
> > > Jason
> > >
> > >
> > > On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org>
> wrote:
> > > >
> > > > Some progress: https://github.com/apache/solr/pull/3829
> > > >
> > > > I think the org.apache.solr.client.solrj package should be used for
> not
> > > > only SolrClient (it's there now) but for HttpSolrClient (now that
> it's
> > > > abstract & simple), but also CloudSolrClient. It's debatable what
> > > belongs
> > > > in "impl"; I don't love that package name TBH. But the classes
> > > > in org.apache.solr.client.solrj should be chosen conservatively
> since we
> > > > have a rich set of sub-packages to organize most things. Thus
> *only* the
> > > > most foundational things that otherwise have no obvious home belong
> in
> > > > org.apache.solr.client.solrj.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Http2SolrClient name...
Posted by Jason Gerlowski <ge...@gmail.com>.
> I'm lukewarm with "SimpleSolrClient"
Fair enough - it's just there by way of example. If we agreed that the
"Http"-prefix was worth reconsidering, I'm sure the group could arrive
at *something* we like better.
> I think HttpSolrClient is a fine name too,
I guess that's where I'm lost. What do you like about the prefix?
Are there benefits or things you like about it beyond the fact that it
has inertia?
To my mind it conveys 0 bits of information. But maybe I'm missing something...
On Thu, Nov 6, 2025 at 1:59 PM David Smiley <ds...@apache.org> wrote:
>
> I'm lukewarm with "SimpleSolrClient". I like that it conveys no additional
> value-add like SolrCloud awareness or load-balancing. However the JDK &
> Jetty impls have some sophistication to their implementations, like async.
> I think HttpSolrClient is a fine name too, plus users and LLMs have already
> become quite aware of it ;-). I don't think it implies a lack of SSL
> support.
>
> My only concern with bringing HttpSolrClient back (or adding
> SimpleSolrClient) is that it doesn't _really_ need to exist as a base
> abstraction. In my PR, it just exposes a URL getter. So what; the caller
> probably should have no need to call that any way. It can be nice in a
> test that wants to manually then use an HttpClient, but it could just as
> well have gotten that URL from Jetty test infra.
>
> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <ge...@gmail.com>
> wrote:
>
> > I was re-reading this thread in preparation to review the PR David
> > mentioned above, and had an interesting thought that hadn't struck me
> > on previous readings. I hate to bring in new ideas at the "11th
> > hour", but I'd also hate to leave it unsaid in case folks think
> > there's something there. So, with my apologies, here goes. Feel free
> > to ignore:
> >
> > > an LLM that knows about
> > > HttpSolrClient's pervasiveness. And who can blame any person or LLM
> > for
> > > using such an obvious name like that. What a great name!
> >
> > ...
> >
> > > "HttpSolrClient" (a great-name)
> >
> > ...
> >
> > > the desirable class name "HttpSolrClient"
> >
> > HttpSolrClient is a much better name to expose to folks than many of
> > the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
> > I think is mostly what David was trying to convey in those quotes
> > above. But is it *really* desirable in a general sense?
> >
> > The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
> > to distinguish these clients from "EmbeddedSolrServer" (which relied
> > on a local SolrCore and didn't send any network traffic). But 10+
> > years on from that decision the "Http" signifier makes much less sense
> > IMO.
> >
> > Today, the common-thread running through our "Http" SolrClients is
> > that (1) they use a single base URL and (2) don't layer on any of the
> > additional logic found in other implementations. At best, the "Http"
> > signifier is disconnected from that commonality and does nothing to
> > convey it. At worst, it's actively misleading: "Oh, I guess these are
> > the only clients that use HTTP then", "Oh, I guess it only supports
> > HTTP and not HTTPS"
> >
> > It'd be a bigger departure, but while we're renaming the clients is it
> > worth considering something without the "Http" prefix altogether? Say,
> > "SingleUrlSolrClient" or "SimpleSolrClient" or something along those
> > lines?
> >
> > Apologies again for bringing this up, and so late at that.
> >
> > Best,
> >
> > Jason
> >
> >
> > On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org> wrote:
> > >
> > > Some progress: https://github.com/apache/solr/pull/3829
> > >
> > > I think the org.apache.solr.client.solrj package should be used for not
> > > only SolrClient (it's there now) but for HttpSolrClient (now that it's
> > > abstract & simple), but also CloudSolrClient. It's debatable what
> > belongs
> > > in "impl"; I don't love that package name TBH. But the classes
> > > in org.apache.solr.client.solrj should be chosen conservatively since we
> > > have a rich set of sub-packages to organize most things. Thus *only* the
> > > most foundational things that otherwise have no obvious home belong in
> > > org.apache.solr.client.solrj.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
I'm lukewarm with "SimpleSolrClient". I like that it conveys no additional
value-add like SolrCloud awareness or load-balancing. However the JDK &
Jetty impls have some sophistication to their implementations, like async.
I think HttpSolrClient is a fine name too, plus users and LLMs have already
become quite aware of it ;-). I don't think it implies a lack of SSL
support.
My only concern with bringing HttpSolrClient back (or adding
SimpleSolrClient) is that it doesn't _really_ need to exist as a base
abstraction. In my PR, it just exposes a URL getter. So what; the caller
probably should have no need to call that any way. It can be nice in a
test that wants to manually then use an HttpClient, but it could just as
well have gotten that URL from Jetty test infra.
On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <ge...@gmail.com>
wrote:
> I was re-reading this thread in preparation to review the PR David
> mentioned above, and had an interesting thought that hadn't struck me
> on previous readings. I hate to bring in new ideas at the "11th
> hour", but I'd also hate to leave it unsaid in case folks think
> there's something there. So, with my apologies, here goes. Feel free
> to ignore:
>
> > an LLM that knows about
> > HttpSolrClient's pervasiveness. And who can blame any person or LLM
> for
> > using such an obvious name like that. What a great name!
>
> ...
>
> > "HttpSolrClient" (a great-name)
>
> ...
>
> > the desirable class name "HttpSolrClient"
>
> HttpSolrClient is a much better name to expose to folks than many of
> the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
> I think is mostly what David was trying to convey in those quotes
> above. But is it *really* desirable in a general sense?
>
> The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
> to distinguish these clients from "EmbeddedSolrServer" (which relied
> on a local SolrCore and didn't send any network traffic). But 10+
> years on from that decision the "Http" signifier makes much less sense
> IMO.
>
> Today, the common-thread running through our "Http" SolrClients is
> that (1) they use a single base URL and (2) don't layer on any of the
> additional logic found in other implementations. At best, the "Http"
> signifier is disconnected from that commonality and does nothing to
> convey it. At worst, it's actively misleading: "Oh, I guess these are
> the only clients that use HTTP then", "Oh, I guess it only supports
> HTTP and not HTTPS"
>
> It'd be a bigger departure, but while we're renaming the clients is it
> worth considering something without the "Http" prefix altogether? Say,
> "SingleUrlSolrClient" or "SimpleSolrClient" or something along those
> lines?
>
> Apologies again for bringing this up, and so late at that.
>
> Best,
>
> Jason
>
>
> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org> wrote:
> >
> > Some progress: https://github.com/apache/solr/pull/3829
> >
> > I think the org.apache.solr.client.solrj package should be used for not
> > only SolrClient (it's there now) but for HttpSolrClient (now that it's
> > abstract & simple), but also CloudSolrClient. It's debatable what
> belongs
> > in "impl"; I don't love that package name TBH. But the classes
> > in org.apache.solr.client.solrj should be chosen conservatively since we
> > have a rich set of sub-packages to organize most things. Thus *only* the
> > most foundational things that otherwise have no obvious home belong in
> > org.apache.solr.client.solrj.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Http2SolrClient name...
Posted by Jason Gerlowski <ge...@gmail.com>.
I was re-reading this thread in preparation to review the PR David
mentioned above, and had an interesting thought that hadn't struck me
on previous readings. I hate to bring in new ideas at the "11th
hour", but I'd also hate to leave it unsaid in case folks think
there's something there. So, with my apologies, here goes. Feel free
to ignore:
> an LLM that knows about
> HttpSolrClient's pervasiveness. And who can blame any person or LLM for
> using such an obvious name like that. What a great name!
...
> "HttpSolrClient" (a great-name)
...
> the desirable class name "HttpSolrClient"
HttpSolrClient is a much better name to expose to folks than many of
the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which
I think is mostly what David was trying to convey in those quotes
above. But is it *really* desirable in a general sense?
The "Http-" prefix was (AFAICT) chosen at a time when it was necessary
to distinguish these clients from "EmbeddedSolrServer" (which relied
on a local SolrCore and didn't send any network traffic). But 10+
years on from that decision the "Http" signifier makes much less sense
IMO.
Today, the common-thread running through our "Http" SolrClients is
that (1) they use a single base URL and (2) don't layer on any of the
additional logic found in other implementations. At best, the "Http"
signifier is disconnected from that commonality and does nothing to
convey it. At worst, it's actively misleading: "Oh, I guess these are
the only clients that use HTTP then", "Oh, I guess it only supports
HTTP and not HTTPS"
It'd be a bigger departure, but while we're renaming the clients is it
worth considering something without the "Http" prefix altogether? Say,
"SingleUrlSolrClient" or "SimpleSolrClient" or something along those
lines?
Apologies again for bringing this up, and so late at that.
Best,
Jason
On Sun, Nov 2, 2025 at 4:39 PM David Smiley <ds...@apache.org> wrote:
>
> Some progress: https://github.com/apache/solr/pull/3829
>
> I think the org.apache.solr.client.solrj package should be used for not
> only SolrClient (it's there now) but for HttpSolrClient (now that it's
> abstract & simple), but also CloudSolrClient. It's debatable what belongs
> in "impl"; I don't love that package name TBH. But the classes
> in org.apache.solr.client.solrj should be chosen conservatively since we
> have a rich set of sub-packages to organize most things. Thus *only* the
> most foundational things that otherwise have no obvious home belong in
> org.apache.solr.client.solrj.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Some progress: https://github.com/apache/solr/pull/3829
I think the org.apache.solr.client.solrj package should be used for not
only SolrClient (it's there now) but for HttpSolrClient (now that it's
abstract & simple), but also CloudSolrClient. It's debatable what belongs
in "impl"; I don't love that package name TBH. But the classes
in org.apache.solr.client.solrj should be chosen conservatively since we
have a rich set of sub-packages to organize most things. Thus *only* the
most foundational things that otherwise have no obvious home belong in
org.apache.solr.client.solrj.
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Eric and Jan agreed/+1 in Slack to moving these to solr-test-framework.
I was asked what the biggest risk in doing such is. The only thing I can
think of, which I dunno is a "risk", but it's what to do about the
existence of the desirable class name "HttpSolrClient". If we move it to
solr-test-framework, the name is still reserved, and thus preventing
creating such a base class. It'd be nasty to have the same name exist in
two packages, even if one is deprecated. At the point we want to use that
name, which will be very very soon if we seek 10.0, I could rename
HttpSolrClient to HttpApacheSolrClient (without changing usages; thus
breaking compile) as previously agreed, and then introduce a base
HttpSolrClient in a separate commit, as the foundation of all such HTTP
SolrClients (3). Then fix compilations by referencing HttpApacheSolrClient
where it's truly needed, intentionally limiting to as few lines as
possible. Such lines (all in tests) will need to eventually migrate
anyway, remember.
On Wed, Oct 15, 2025 at 8:50 PM David Smiley <ds...@apache.org> wrote:
> Alternatively... I could just move these ones into solr-test-framework,
> where they will live a short life in 10.x until they can completely be
> removed. It solves a problem of how to exclude the Apache HttpClient JARs
> from the Solr server -- SOLR-17962 (I created just now; please look). It
> also doesn't disrupt some large WIP I have currently on the backburner to
> update the tests.
>
> On Wed, Oct 15, 2025 at 8:09 PM David Eric Pugh <de...@yahoo.com.invalid>
> wrote:
>
>> I think now is the best time to deal with this! So many of the
>> deprecations etc are all around this space, and it's super confusing.
>> On Wednesday, October 15, 2025 at 04:21:52 PM EDT, David Smiley <
>> dsmiley@apache.org> wrote:
>>
>> I propose that I execute at least part of this plan Thursday night for
>> main
>> branch, backport to 10 straight away:
>> * remove BaseHttpSolrClient, the deprecated base class of HttpSolrClient
>> * rename HttpSolrClient to HttpApacheSolrClient
>> * rename CloudLegacySolrClient to CloudApacheSolrClient
>> * rename LBHttpSolrClient to LbApacheSolrClient (lowercase 'b')
>> * rename ConcurrentUpdateSolrClient to ConcurrentUpdateApacheSolrClient
>> * rename HttpClusterStateProvider to HttpApacheClusterStateProvider
>>
>> I will do that purely mechanically by IntelliJ IDEA. The PR will be no
>> fun
>> to look at and will have no other changes whatsoever to review. Ref
>> guide,
>> CHANGES.txt, can be in another PR (commit) so that it's not lost in a sea
>> of wrote changes.
>>
>> The above only changes deprecated clients. "HttpSolrClient" (a
>> great-name)
>> won't exist but let's add afterwards/soon. The rest of the renames can be
>> in a follow-up, that I'll announce on this thread. I could do likewise
>> for
>> the other clients. I'm aware of work James is doing so I don't want to
>> disturb that at the moment.
>>
>> If I get a couple +1 and no dissent, I'll proceed.
>>
>> On Mon, Sep 29, 2025 at 1:40 PM James Dyer <jd...@gmail.com> wrote:
>>
>> > I agree with all the "HTTP" renames proposed here. I do want to point
>> > out that with the Load Balanced client, we opted to make
>> > `LBHttp2SolrClient` work with both the Jetty and JDK client variants.
>> > (see https://github.com/apache/solr/pull/2828) My hope is that the
>> > same can be done for both `CloudSolrClient` and
>> > `ClusterStateProvider`. For these more-advanced clients that really
>> > just layer on more functionality, we should try not have a bespoke
>> > variant for each underlying base client implementation. With that in
>> > mind, the less-specific the naming the better.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > For additional commands, e-mail: dev-help@solr.apache.org
>> >
>> >
>>
>
>
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
Alternatively... I could just move these ones into solr-test-framework,
where they will live a short life in 10.x until they can completely be
removed. It solves a problem of how to exclude the Apache HttpClient JARs
from the Solr server -- SOLR-17962 (I created just now; please look). It
also doesn't disrupt some large WIP I have currently on the backburner to
update the tests.
On Wed, Oct 15, 2025 at 8:09 PM David Eric Pugh <de...@yahoo.com.invalid>
wrote:
> I think now is the best time to deal with this! So many of the
> deprecations etc are all around this space, and it's super confusing.
> On Wednesday, October 15, 2025 at 04:21:52 PM EDT, David Smiley <
> dsmiley@apache.org> wrote:
>
> I propose that I execute at least part of this plan Thursday night for
> main
> branch, backport to 10 straight away:
> * remove BaseHttpSolrClient, the deprecated base class of HttpSolrClient
> * rename HttpSolrClient to HttpApacheSolrClient
> * rename CloudLegacySolrClient to CloudApacheSolrClient
> * rename LBHttpSolrClient to LbApacheSolrClient (lowercase 'b')
> * rename ConcurrentUpdateSolrClient to ConcurrentUpdateApacheSolrClient
> * rename HttpClusterStateProvider to HttpApacheClusterStateProvider
>
> I will do that purely mechanically by IntelliJ IDEA. The PR will be no fun
> to look at and will have no other changes whatsoever to review. Ref guide,
> CHANGES.txt, can be in another PR (commit) so that it's not lost in a sea
> of wrote changes.
>
> The above only changes deprecated clients. "HttpSolrClient" (a great-name)
> won't exist but let's add afterwards/soon. The rest of the renames can be
> in a follow-up, that I'll announce on this thread. I could do likewise for
> the other clients. I'm aware of work James is doing so I don't want to
> disturb that at the moment.
>
> If I get a couple +1 and no dissent, I'll proceed.
>
> On Mon, Sep 29, 2025 at 1:40 PM James Dyer <jd...@gmail.com> wrote:
>
> > I agree with all the "HTTP" renames proposed here. I do want to point
> > out that with the Load Balanced client, we opted to make
> > `LBHttp2SolrClient` work with both the Jetty and JDK client variants.
> > (see https://github.com/apache/solr/pull/2828) My hope is that the
> > same can be done for both `CloudSolrClient` and
> > `ClusterStateProvider`. For these more-advanced clients that really
> > just layer on more functionality, we should try not have a bespoke
> > variant for each underlying base client implementation. With that in
> > mind, the less-specific the naming the better.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
Re: Http2SolrClient name...
Posted by David Eric Pugh <de...@yahoo.com.INVALID>.
I think now is the best time to deal with this! So many of the deprecations etc are all around this space, and it's super confusing.
On Wednesday, October 15, 2025 at 04:21:52 PM EDT, David Smiley <ds...@apache.org> wrote:
I propose that I execute at least part of this plan Thursday night for main
branch, backport to 10 straight away:
* remove BaseHttpSolrClient, the deprecated base class of HttpSolrClient
* rename HttpSolrClient to HttpApacheSolrClient
* rename CloudLegacySolrClient to CloudApacheSolrClient
* rename LBHttpSolrClient to LbApacheSolrClient (lowercase 'b')
* rename ConcurrentUpdateSolrClient to ConcurrentUpdateApacheSolrClient
* rename HttpClusterStateProvider to HttpApacheClusterStateProvider
I will do that purely mechanically by IntelliJ IDEA. The PR will be no fun
to look at and will have no other changes whatsoever to review. Ref guide,
CHANGES.txt, can be in another PR (commit) so that it's not lost in a sea
of wrote changes.
The above only changes deprecated clients. "HttpSolrClient" (a great-name)
won't exist but let's add afterwards/soon. The rest of the renames can be
in a follow-up, that I'll announce on this thread. I could do likewise for
the other clients. I'm aware of work James is doing so I don't want to
disturb that at the moment.
If I get a couple +1 and no dissent, I'll proceed.
On Mon, Sep 29, 2025 at 1:40 PM James Dyer <jd...@gmail.com> wrote:
> I agree with all the "HTTP" renames proposed here. I do want to point
> out that with the Load Balanced client, we opted to make
> `LBHttp2SolrClient` work with both the Jetty and JDK client variants.
> (see https://github.com/apache/solr/pull/2828) My hope is that the
> same can be done for both `CloudSolrClient` and
> `ClusterStateProvider`. For these more-advanced clients that really
> just layer on more functionality, we should try not have a bespoke
> variant for each underlying base client implementation. With that in
> mind, the less-specific the naming the better.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
I propose that I execute at least part of this plan Thursday night for main
branch, backport to 10 straight away:
* remove BaseHttpSolrClient, the deprecated base class of HttpSolrClient
* rename HttpSolrClient to HttpApacheSolrClient
* rename CloudLegacySolrClient to CloudApacheSolrClient
* rename LBHttpSolrClient to LbApacheSolrClient (lowercase 'b')
* rename ConcurrentUpdateSolrClient to ConcurrentUpdateApacheSolrClient
* rename HttpClusterStateProvider to HttpApacheClusterStateProvider
I will do that purely mechanically by IntelliJ IDEA. The PR will be no fun
to look at and will have no other changes whatsoever to review. Ref guide,
CHANGES.txt, can be in another PR (commit) so that it's not lost in a sea
of wrote changes.
The above only changes deprecated clients. "HttpSolrClient" (a great-name)
won't exist but let's add afterwards/soon. The rest of the renames can be
in a follow-up, that I'll announce on this thread. I could do likewise for
the other clients. I'm aware of work James is doing so I don't want to
disturb that at the moment.
If I get a couple +1 and no dissent, I'll proceed.
On Mon, Sep 29, 2025 at 1:40 PM James Dyer <jd...@gmail.com> wrote:
> I agree with all the "HTTP" renames proposed here. I do want to point
> out that with the Load Balanced client, we opted to make
> `LBHttp2SolrClient` work with both the Jetty and JDK client variants.
> (see https://github.com/apache/solr/pull/2828) My hope is that the
> same can be done for both `CloudSolrClient` and
> `ClusterStateProvider`. For these more-advanced clients that really
> just layer on more functionality, we should try not have a bespoke
> variant for each underlying base client implementation. With that in
> mind, the less-specific the naming the better.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Http2SolrClient name...
Posted by James Dyer <jd...@gmail.com>.
I agree with all the "HTTP" renames proposed here. I do want to point
out that with the Load Balanced client, we opted to make
`LBHttp2SolrClient` work with both the Jetty and JDK client variants.
(see https://github.com/apache/solr/pull/2828) My hope is that the
same can be done for both `CloudSolrClient` and
`ClusterStateProvider`. For these more-advanced clients that really
just layer on more functionality, we should try not have a bespoke
variant for each underlying base client implementation. With that in
mind, the less-specific the naming the better.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Http2SolrClient name...
Posted by David Smiley <ds...@apache.org>.
I've been thinking exactly this thing, and here you proposed it :-). I also
mentioned it to Jason at the hackathon.
People expect to have an "HttpSolrClient" type; the recent Solr MCP was
using it -- perhaps written in part by an LLM that knows about
HttpSolrClient's pervasiveness. And who can blame any person or LLM for
using such an obvious name like that. What a great name! Our issue as a
project is the *implementation*.
HTTP:
* HttpSolrClient base type; not much if any implementation
* HttpJettySolrClient (formerly known as Http2SolrClient)
* HttpApacheSolrClient (formerly HttpSolrClient).
* HttpJdkSolrClient (already named well).
CLOUD:
* CloudSolrClient base type
* CloudJettySolrClient (from CloudHttp2SolrClient)
* CloudApacheSolrClient (currently CloudLegacySolrClient). One could argue
just leave it be given how soon it will be deleted
* (no JDK variant exists yet, sadly)
LB:
(I dislike that the B is capitalized; would prefer to lowercase that)
* LBSolrClient base type
* LBJettySolrClient (from LBHttp2SolrClient)
* LBApacheSolrClient (from LBHttpSolrClient)
* (no JDK variant exists yet)
CONCURRENT UPDATE
* NO ConcurrentUpdateSolrClient base abstraction needed? Or just add it
with nothing
* ConcurrentUpdateApacheSolrClient (from ConcurrentUpdateSolrClient)
* ConcurrentUpdateJettySolrClient (from ConcurrentUpdateHttp2SolrClient)
Using a sequence of "git mv" operations on multiple commits, we could
retain source control history, even though the project wouldn't build at a
specific intermediary commit.
All that would be Solr 10 only, but Solr 9 could un-deprecate
HttpSolrClient along with documentation explaining what's happening.
Of course, all of this will be quite disruptive to anyone with WIP on these
very classes. James Dyer, I'm thinking of you.
On Sat, Sep 27, 2025 at 7:57 AM David Eric Pugh <de...@yahoo.com.invalid>
wrote:
> Looking at Http2SolrClient after talking to David S the other day, and boy
> is it confusing. I thought it was the "client that speaks Http 2", not
> "the second Http Client that speaks 1 and 2".
> We have a javadoc:* <p>Despite the name, this client supports HTTP 1.1 and
> 2 -- toggle with {@link
> * HttpSolrClientBuilderBase#useHttp1_1(boolean)}. In retrospect, the name
> should have been {@code
> * HttpJettySolrClient}.With Solr 10 coming up, should we have a
> HttpJettySolrClient that then is extended by Http2SolrClient and go ahead
> and deprecate Http2SolrClient?
> Or, just rip the bandaid off, and deprecate Http2SolrClient in 9x, and
> introduce HttpJettySolrClient in 10? I'm guessing usage of
> Http2SolrClient out in the wild isn't yet prevalent.
> Or neither...