You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by GitBox <gi...@apache.org> on 2019/12/27 13:39:49 UTC
[GitHub] [lucene-solr] noblepaul edited a comment on issue #1124: SOLR-14151
:Schema components to be loadable from packages
noblepaul edited a comment 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
The current behavior is not correct. We should invoke `inform(ResourceLoader)` soon after the objects are constructed b/c a package Loader is ready even before
----------------------------------------------------------------
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:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org