I'd love to see some of the ideas come to fruition. Having said that, here
are two PR's that would solve my specific issues:
First, https://github.com/apache/solr/pull/4091which adds NoOpResponseWriter
and NoOpRequestWriter. Hoss, you mentioned this a while ago as a undocumented
"tip" and then I discovered I removed them as part of a different PR! This PR
restores them more narrowly and adds them to Ref Guide. I hope this is pretty
un-controversial.
Maybe a bit more controversial is https://github.com/apache/solr/pull/4066
which lets you delete using the Config API any implicitly created writers and
handlers. It feels like if I want to delete through the Config API a request
handler or writer than I should be able to and that is a nicer lifecycle! I'd
love a plus one on this, or a clearer "yeah, we aren't doing this" so the PR
doesn't linger.
On Friday, February 13, 2026 at 07:47:51 PM EST, David Smiley
<[email protected]> wrote:
On Fri, Feb 13, 2026 at 1:27 PM Chris Hostetter <[email protected]>
wrote:
>
> What if we take a step back, and start focusing more on using SPI for
> "finding" and registering more plugins?
+1 for SPI for its own sake...
> Not just in terms of finding
> plugins "by name" but also finding *implicit* plugins "by type"
... but I don't get the relationship between SPI and what you describe...
> At which "FooBarBazRequestHandler" could live in it's own module but
> could *ALSO* be implicit if that module is loaded at run-time.
>
> So solr could say "The recommended SOLR_MODULES are xml,csv,json,..." and
> if you load those then ever collection will implicitly have
> request handlers like /update/xml, /update/csv, update/json (and their
> underlying ContentStreamLoaders for /update) and response writers like
> wt=xml, wt=csv, wt=json.
Maybe what you're implying is that our plugins should be
extremely compartmentalized/modularized so that each and every one becomes
a JAR/module that can be included/excluded? Every handler gets its own JAR?
Sounds like crazy talk but one thing I would like about that approach is
being able to attribute CVEs more precisely to certain JARs. Everyone who
chooses not to use security plugins (which is most people) thus doesn't get
ding'ed by CVE scanners.
~ David
