You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Chris Hostetter <ho...@fucit.org> on 2026/02/13 18:27:14 UTC
Re: Nicer lifecycle handling of built in RequestHandlers and QueryResponseWriters
I'm catching up on mail, and what like to throw another monkey wrench
/straw man into the mix for consideration...
: 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?
What if we take a step back, and start focusing more on using SPI for
"finding" and registering more plugins? Not just in terms of finding
plugins "by name" but also finding *implicit* plugins "by type"
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.
But if you *DON'T* include those modules at runtime, then they won't be
implicit.
(Plus all the current options: if you explicitly declare a
handler/responsewriter/etc with a name & a class, then the SolrCore won't
load unless the class can be found, and that name will be bound to it even
if an "implicit" handler -- that is in a loaded module -- would typically
use that name)
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Nicer lifecycle handling of built in RequestHandlers and QueryResponseWriters
Posted by David Eric Pugh via dev <de...@solr.apache.org>.
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 <ds...@apache.org> wrote:
On Fri, Feb 13, 2026 at 1:27 PM Chris Hostetter <ho...@fucit.org>
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
Re: Nicer lifecycle handling of built in RequestHandlers and QueryResponseWriters
Posted by David Smiley <ds...@apache.org>.
On Fri, Feb 13, 2026 at 1:27 PM Chris Hostetter <ho...@fucit.org>
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