Hey all, Sorry for joining this discussion late. I only caught it after seeing the PR Eric linked above and getting curious.
I guess the main point that I want to interrogate a bit is: do we *really* need the ability for folks to customize these built-ins on a core-by-core basis? Or are we designing for a use-case that may not exist in practice? Someone disabling (e.g.) CSV everywhere for security reasons makes sense to me. But it's harder for me to picture a case where a user would absolutely *need* to disable one of our built-ins, but only on select cores. Have we seen that in the field anywhere? If that wrinkle disappears, I think it'd hugely simplify what we need to do here. Eric's current PR to add more "types" to ImplicitPlugins.json seems like an excellent first step. But I worry about the complexity of some of the subsequent steps, particularly letting users define their own ImplicitPlugins.json in each configset. It's the sort of thing that makes sense to us devs with deep knowledge of how Solr exists today, but that IMO would be really inexplicable to a new user. "Wait, what is this ImplicitPlugins.json thing? It defines per-core plugins? But isn't that what solrconfig.xml is already for? How do I know what goes in each one?" I'm not vetoing that route necessarily, but I want to make sure it serves a real use case before we start down that road. Best, Jason On Tue, Jan 27, 2026 at 11:13 AM David Eric Pugh via dev <[email protected]> wrote: > > 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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
