noblepaul commented on issue #1124: SOLR-14151 :Schema components to be loadable from packages URL: https://github.com/apache/lucene-solr/pull/1124#issuecomment-569269915 > I see this introduces a new interface "PluginLoader" that is implemented by SolrResourceLoader and a new PackageAwarePluginLoader, and that it's only the latter that parses out the plugin information from a class name and not SolrResourceLoader (unlike the approach in my hackday). Avoiding SolrResourceLoader doing this is only feasible for Solr specific plugin loading code but not for code in Lucene that is based on a Lucene ResourceLoader. Just one example is SynonymGraphFilterFactory that can _itself_ load a Tokenizer and Analyzer via a provided ResourceLoader. Having SolrResourceLoader itself do plugin resolution will resolve this and doesn't introduce new abstractions (e.g. PluginLoader). WDYT? I have renamed `PluginLoader` -> `SolrClassLoader` in the the latest commit We need abstractions. Using concrete impls is one of the biggest reasons why we have very little modularity. So, the solution to the problem is we will make `SolrClassLoader extends ResourceLoader` and this will be the interface which will be passed around. We will stop relying on SRL because SRL does too many things already. Piling on more things into an already bloated class is at best a hack. It's not a good idea to say that A package retsurns an SRL because most of the methods are invalid for such a use case
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
