I'm so glad I pushed for more discussion on this topic initially because I'm loving your feedback, Jason!
Huge +1 from me to shift the config file lookup to be in a "server" location instead of the configSet. In time, a new issue, we can switch ImplictPlugins.json to be just another solrconfig.xml. I would friggin love that. It'd essentially be a foundational aspect/implementation approach to "configSet inheritance" -- SOLR-17816. At the moment, we have bespoke code that knows to look in ImplicitPlugins for certain plugins. Instead I propose the XML DOM be produced from multiple sources. that maybe reads the XML event stream synthesized from multiple sources, after which we need not have bespoke code on a per-plugin basis. We could do similarly with the schema to declare default field types (e.g. numerics). On Wed, Jan 28, 2026 at 10:18 AM Jason Gerlowski <[email protected]> wrote: > 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] > >
