Jason, Hopefully you found/read https://issues.apache.org/jira/browse/SOLR-18079 (which precipitated Eric's email) especially my first comment.
You will see that I am *also* concerned about exposing a file that I don't think is meant for public consumption. My compromise (Jan agrees) is to deem this file internal/experimental, and I'm placated but we'll ideally want something better someday. FWIW I don't like the idea of declaring a handler disabled/deleted in some way. Instead, I'd rather see a file that we *do* like, maybe a file that meets the syntax of solrconfig.xml, and use this file to configure what's in ImplicitPlugins.json albeit instead in XML using a schema we document/support/understand. What's new would be a kind of inheritance mechanism to indicate the relationship between two files of solrconfig.xml's syntax & schema -- the one that is for the configset, and another that is a root/inherited one. I have some loose ideas on configset inheritance here: https://issues.apache.org/jira/browse/SOLR-17816 If we embark on such a road, I think a real up-front design is warranted. ~ David On Wed, Jan 28, 2026 at 8:20 AM Jason Gerlowski <[email protected]> wrote: > 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] > >
