We've made good progress ont he first part of the work: 
https://github.com/apache/solr/pull/4073.     I plan on merging this soon, and 
then rolling out a second PR that lets you customize per configset what query 
response writers and request handlers are configured.


    On Friday, January 23, 2026 at 12:08:49 PM EST, David Eric Pugh via dev 
<[email protected]> wrote:  
 
  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.

    

Reply via email to