: I need a new feature in solr : to allow the configuration of the
: IndexSearcher class in the schema configuration to override the lucene
: IndexSearcher .
I haven't had a chance to look at the patch you submited yet, but can you
elaborate on your use case? There's another open issue relating to
configuring the IndexReader to be used, and i'm wondering if btoh issues
are symptomatic of a common problem/goal and hould be considered together.
(alternately, there may already be a different way to achieve what you
want to do easier then overriding the IndexSearcher we might be able to
suggest.)
: I'd like to allow a new tag in the schema :
minor nit: a config option like this should probably go in the
solrconfig.xml .. the schema.xml is where information about the index
itself lives, what the fields nd field types are, what similarity to use
based on the nature of hte data ... options relating to how you want this
particular instance of Solr to behave should go in the solrconfig.xml --
what request handlers to use, what caching to use, etc.
: I dont exactly know what is the best way to do it.
: I was think of:
...
: String idxSearcherClassName = schema.getLuceneIndexSearcherClassName()
: // Then load the class itself
: // Then build a new instance of this class with the IndexReader r
:
: What solr special class loader and instance builder do I have to use
: to do the last two operation ?
There is a custom classloader specificly designed for retrieving pluggin
classes, the most direct way to load classes is with
Config.findClass(className, defaultSolrSearchPackagages)
two thing that are usually important to think about when creating new
"plugin" points are;
1) reflection costs
2) configuration options
for things like Tokenizers and TokenFilters, they are instantiated so
often that we the plugins we use are actually factories -- that way the
reflection cost is only paid once at startup ... for something like an
IndexSearcher this may not be as crucial, since they are only created when
a new Indexreader is opened, but the second point may still be an issue --
you could assume that all possible IndexSearcher subclasses will be
constructed using a single argument constructor that takes in an
idnexreader -- but that really limits the scope of what people can do in
their custom subclassees (which kind of defeats the point of a plugin)
creating a new IndexSearcherFactory class/interface let's you define some
basic methods for plgin writers to get config info and then instantiate
their concrete IndexSearcher implementation any way they want.
just recently some abstract base classes have been commited that make this
really easy, take a look at the o.a.solr.util.plugin package.
-Hoss
