I'm going to modify the existing https://github.com/apache/solr/pull/4073 to
move in the direction of having a BUILTIN set of ResponseWriters seperate from
the ones you access via the core.
As far as the fourth item, yeah, maybe it's not needed when you have the
ImplicitPlugins.json loaded from configset. It seems a bit odd that you can't
delete those items when we have this configoverlay concept. Feels like if you
can create things then you would also expect to delete things, regardless of
how they are created. The code didn't seem that convoluted
https://github.com/apache/solr/pull/4066/files.
However, if it's a just me thing, then totally get it. My underlying usecase
doesn't require it either. It just felt odd that I couldn't delete something
after starting Solr up that appeared to be a configurable type thing.
On Thursday, January 22, 2026 at 04:38:30 PM EST, David Smiley
<[email protected]> wrote:
I realize my thoughts on QueryResponseWriters being misplaced doesn't really
matter for 10.x and prior.
I think your proposal for segmenting them is fine, but please declare the
BUILTIN ones *not* in SolrCore. It's a detail; happy to code review. We can
change what's built-in and not over time.
On Thu, Jan 22, 2026 at 3:32 PM David Smiley <[email protected]> wrote:
Thanks for discussing these things...
On Thu, Jan 22, 2026 at 2:05 PM David Eric Pugh via dev <[email protected]>
wrote:
However, I wanted to bring this to the larger dev community for disucssion.
Here is what I'm thinking:
1) Separate out the existing SolrCore.DEFAULT_RESPONSE_WRITERS that holds all
the response writers into two groups. SolrCore.ADMIN_RESPONSE_WRITERS would
contain the json,javabin, prometheus/openmetrics, and maybe xml writers as they
are used across Solr outside of a core. The rest of the writers would
continue to live in SolrCore.DEFAULT_RESPONSE_WRITERS.
2) Then, migrate DEFAULT_RESPONSE_WRITERS response writers that are core
specific to using the existing ImplicitPlugins.json file for configuration.
This would centralize a bit where we create our defaults.
RE 1 & 2: Why separate some from others? Assuming we desire this separation,
I don't think "ADMIN" would be the distinguishing word... more like "BUILTIN".
I'm surprised that response writers even exist at a SolrCore level. I've known
this but have felt it makes no sense. They are consulted at HttpSolrCall level
(above individual cores). I see it as very awkward how it reaches into the
core to get one, and has to make special accomodations for admin/internal
situations. To me, they should be node level plugins, not
changeable/configurable at core/configset level. The current situation is
probably an accident of history, one that wasn't thought through. IMO
registering/customizing them should be in solr.xml.
3) Add support for a configset level "ImplicitPlugins.json" file that if it
exists is used instead of the global "ImplicitPlugins.json", which would allow
me to remove the CSV related handlers and query response type.
+1 (naturally; my idea). Albeit the name/format/existence of this file is
something I'd like to be deemed as "experimental" / subject to change.
4) Enhance configoverlay.json to allow you to delete any request handlers or
request writers and track that deleted status in the configoverlay.json file,
which would offer up a full lifecycle via the config API.
Ehhh, -1 veto; because it appears needless given a user-definable
ImplicitPlugins.json. I think it's simpler to code/maintain/document that you
can only delete a plugin that you register with that API. AFAIK that's how it
works now but correct me if I'm wrong.
