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.
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.
