Hey Gang,
I am implementing https://issues.apache.org/jira/browse/SOLR-342 and
have it working (just testing now, hope to have a patch today or
tomorrow) and came across a bit that I don't quite understand.
Currently, in order to support setting Lucene's merge policy and
merge scheduler, I need to be able to create a new instance of these
classes (possibly) in SolrIndexWriter. Great, I figured I could just
call Config.newInstance() and all would be happy. However, the
SolrIndexConfig is not an instance of Config, due to loading
optimization issues.
So now, as a workaround, I have the following code in SolrIndexWriter
(in the init method):
MergePolicy policy = (MergePolicy) schema.getSolrConfig().newInstance
(config.mergePolicyClassName);
setMergePolicy(policy);
While this works, it just seems a bit clunky as a way to get at the
SorlConfig. So then, I thought, why does newInstance(), findClass(),
etc. need to be member methods instead of statics? The reason, from
what I can tell, is b/c getClassLoader() stores an instance of the
ClassLoader. What I was wondering is if this could be made static?
Then, I could refactor all of the class loading stuff off into a
ClassUtils helper, and then in SolrIndexWriter, all I would need is:
MergePolicy policy = ClassUtils.newInstance
(config.mergePolicyClassName);
The note on the ClassLoader variable in Config.java says:
/** Singleton classloader loading resources specified in any configs */
seems a bit mysterious too me. On the one hand, it seems to want to
be a singleton, but I don't see that in the code, since getClassLoader
() really just enables lazy loading of the loader and prevents it
from loading the Solr home lib/ directory more than once, right?
Any thoughts?
FWIW, I have already refactored the class loading stuff to
ClassUtils, except the methods have been slightly modified to pass in
the ClassLoader. Config just delegates to ClassUtils, passing the
value of getClassLoader().
Thanks,
Grant
