That’s a good idea too Jan! On Sun, Dec 14, 2025 at 7:43 AM Jan Høydahl <[email protected]> wrote:
> I proposed earlier the opposite. That solrconfig (above a certain > luceneMatchVersion), would support a new tag to explicitly add the magic > default handlers, e.g. <defaultHandlers spec="defaultHandlers.json"/> and > perhaps <defaultResponseWriters/> etc. This is more transparent and > explicit. > > Jan Høydahl > > > 14. des. 2025 kl. 04:53 skrev David Smiley <[email protected]>: > > It's unfortunate a user can't customize the default. I could imagine > > theoretically a number of ways we might make that work. Maybe one would > be > > for the solrconfig.xml to indicate somehow that it should not inherit any > > other plugins (at all). Register everything that you use. > > > >> On Sat, Dec 13, 2025 at 8:24 AM David Eric Pugh via dev < > [email protected]> > >> wrote: > >> > >> I then started looking at the writer types, as I've used configapi to > >> modify the json one in the past. RequestHandlers are set up via > >> ImplicitPlugins.json, but writer types aren't: > >> Query Response Writers vs Request Handlers > >> > >> Here's how query response writers are handled differently from request > >> handlers: > >> > >> Request Handlers > >> > >> - Defined in: ImplicitPlugins.json (as you can see with /update/csv) > >> - Format: JSON configuration file with explicit handler definitions > >> - Registration: Loaded from ImplicitPlugins.json and merged > >> with solrconfig.xml definitions > >> > >> Query Response Writers > >> > >> - NOT in ImplicitPlugins.json - They're handled completely differently > >> - Defined in: SolrCore.java as > >> hard-coded DEFAULT_RESPONSE_WRITERS (static initialization block, lines > >> 3093-3109) > >> - Registration: > >> - Hard-coded defaults are created in a static block in > SolrCore.java > >> - Additional writers can be defined > >> in solrconfig.xml using <queryResponseWriter> tags > >> - The PluginBag.init() method merges solrconfig.xml definitions > with > >> the defaults > >> > >> > >> Does this matter? Seems odd to have two ways to do the same basic > thing. > >> If I wanted to remove CSV as a update type and a witertype, thoughts on > >> how to do it? Without just going in and doing a custom build of Solr? > >> Does adding/removing writer types and request handlers come up for > anyone > >> else? This is for someone who is looking for a very locked down > version of > >> Solr, but doens't want a custom build. > >> Eric > >> > >> On Friday, December 12, 2025 at 05:45:30 PM EST, Houston Putman < > >> [email protected]> wrote: > >> > >> Yeah, I think the config api really only touches the configoverlay.json. > >> So > >> it makes sense to me that it could only delete things that it originally > >> made. > >> > >> - Houston > >> > >> On Fri, Dec 12, 2025 at 11:57 AM David Eric Pugh via dev < > >> [email protected]> wrote: > >> > >>> I was playing around with the Config API, and I wanted to remove the > >>> /update/csv request handler. I expected just to run: > >>> curl -X POST -H 'Content-type:application/json' -d '{ > >>> "delete-requesthandler": "/update/csv" > >>> }' http://localhost:8983/solr/techproducts/config > >>> However I get back an error. Reading the ref guide > >> > https://solr.apache.org/guide/solr/latest/configuration-guide/config-api.html#commands-to-modify-the-config > >> it > >>> seems to suggest that while I can delete a request handler I create > using > >>> the Config API, I can't delete one that comes with Solr? > >>> Does this resonate with other folks? Why can't I use Config API to > >> remove > >>> any request handler? Is it because we only delete things that exist in > >>> the configoverlay.json file? > >>> Eric > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
