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