cpoerschke commented on PR #931: URL: https://github.com/apache/solr/pull/931#issuecomment-1180705616
Hello @ijioio! Thanks for the detailed notes both on the https://issues.apache.org/jira/browse/SOLR-16282 JIRA and the pull request here, they really help with understanding of the existing code and the proposed changes to it! I like the idea of custom actions being pluggable rather than `CoreAdminHandler` needing to be sub-classed. It's a bit subjective of course but the `solr.xml` needing to be changed, that seems a bit of a burden, both operationally and in terms of code complexity? I wonder if there might be some way to dynamically discover actions e.g. if the action was a fully qualified class path and `CoreAdminHandler` had access to `SolrResourceLoader` then could `SolrResourceLoader.newInstance` instantiate the action on demand? ``` http://localhost:8983/solr/admin/cores?action=com.ijioio.solr.action.FooAction ``` From a use point of view the action being a class path seems not very nice though. We could make up some convention where the pluggable class always starts with (say) `CustomCoreAdminOp` and where the action follows after that (say) `CustomCoreAdminOpFoo` but I don't know if going from `foo` action to `CustomCoreAdminOpFoo` class name would be enough to actually instantiate an object. Plus there could be two classes with the same name in different name spaces. Hmm. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
