You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2007/10/25 20:43:46 UTC
Config.getClassLoader()
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
Re: Config.getClassLoader()
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
they can't be statics, because each SolrConfig will have it's own
ClassLoader (because each SOLR_HOME will have it's own lib dir with custom
plugins)
: 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
That's an old comment, from before the multi-core changes (the class
loader was a singleton back when the config and core where singletons)
i'll change it.
-Hoss