lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Upgrading Lucene
Date Thu, 06 Aug 2009 12:36:34 GMT
Grant Ingersoll wrote:
> On Aug 5, 2009, at 6:07 PM, Mark Miller wrote:
>> Mark Miller wrote:
>>> Grant Ingersoll wrote:
>>>> On Aug 3, 2009, at 8:21 PM, Mark Miller wrote:
>>>>> 4. You cannot instantiate MergePolicy with a no arg constructor 
>>>>> anymore - so that fails now. I don't have a fix for this at the 
>>>>> moment.
>>>> That sounds like a back compat break ;-)
>>> It was - but they knew it would be and decided it was fine. The 
>>> methods on the class were package private, so it appeared 
>>> reasonable. The class was also labeled as expert and subject to 
>>> sudden change. I guess it was fair game to break - I don't think 
>>> this scenario was thought of, but I would think we can work around 
>>> it. I havn't really thought about it yet myself though.
>> So this is a bit tricky I guess. The way they handled this in Lucene 
>> Benchmark is:
>> writer.setMergePolicy((MergePolicy) 
>> Class.forName(mergePolicy).getConstructor(new Class[] { 
>> IndexWriter.class }).newInstance(new Object[] { writer }));
>> Now if we handle it the same way, thats fine. But then you can't put 
>> one of these in solr.home/lib. To do that, you have to use 
>> SolrResourceLoader.newInstance - which requires a no arg constructor.
> There's a newInstance on SolrResourceLoader that can take args, if 
> that helps.
Ah, nice - I think it does. I kept glossing over it and just saw:   
public Object newInstance(String cname, String ... subpackages)

There is also   public Object newInstance(String cName, String [] 
subPackages, Class[] params, Object[] args)

Thanks - it looks like it should work.

>> I think we can do something like: create an object with 
>> SolrResourceLoader that loads the MergePolicy - it can use 
>> Class.forName like above because it will use the Classloader of the 
>> object that invoked it. But I'd rather not go there if we don't have 
>> to. This is a pretty advanced plugin, and likely just intended for 
>> picking between included Lucene impls. Do we want to make sure it can 
>> still be loaded from solr.home/lib?
> We could require that any implementations take a writer.  I think we 
> need a better way of taking in arbitrary attributes.  Basically, 
> Spring or GUICE or whatever, but that isn't going to happen overnight.
Right - and we want to upgrade now :) Looks like we have the 
functionality we need though, thanks !

- Mark

View raw message