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.
