Hey, Yep, I saw the discussion on SOLR-18079.
And I love some of the improvements suggested there (and in this mail thread): treating the feature as "experimental", making the file syntax similar to solrconfig.xml, expanding it to cover other plugin types, etc. I'm +1 to all of that. I guess the particular bit I'm unconvinced about is that the base/parent file should be something users (even advanced ones) specify on a per configset basis. Is that **really** something folks are going to need? Or would the "single base/parent for all cores" approach that we have today with ImplicitPlugins.json actually work pretty well if (1) it was moved to "server/etc" or somewhere that admins could edit it, and (2) it covered other plugin types like responseWriter, etc. It seems like that addresses Eric's initial use-case here and most of the other ones I could imagine. Best, Jason On Wed, Jan 28, 2026 at 9:32 AM David Smiley <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
