Hi all..   I've got a need to be able to remove the CSV based input/outpus from 
Solr.   While I've learned some tips and tricks for how to do this, I'd really 
like a Solr "native" way of removing a ResponseWriter and RequestHandler.
I've done some digging, with some good discussion in:
* https://issues.apache.org/jira/browse/SOLR-18079 Allow users to provide their 
own ImplicitPlugins.json* https://github.com/apache/solr/pull/4067 (related PR 
for above)* https://issues.apache.org/jira/browse/SOLR-18078 Allow "deletion" 
of automatically created request handlers and query response writers via API* 
https://github.com/apache/solr/pull/4066 (related PR for above)* 
https://github.com/apache/solr/pull/4073 Moves core specific ResponseWriters 
into ImplicitPlugins.json for setup.

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.
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.
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.
I believe this would go a long way towards making it easier for folks to modify 
Solr and let them make their own decisions on if certain endpoints are not 
acceptable.   Maybe there might be a small gain in performance if you don't use 
certain types of default capabilities too?
Thoughts?  Alternatives that I haven't thought about?   
Eric

Reply via email to