: - if no factory can be found, an attempt will be made to construct : one dynamically (easiest would be to create a generic factory that : works via reflection). People could use simple filters w/o creating a : factory for it.
I think i mentioned this before ... my opinion depends on what the performance impacts are -- if reflection costs are "high" because of class resolution, but instantiation times are roughly the same, then i'm for it because we can resolve the Class once at startup; but if the performance differnece is still significant, i vote vote we force people who want to mix and match custom Filters/Tokenizers to write Factories for them -- it doesn't penalyze people who have custom Analyzers, those don't require Factories, but if you want to mix and match you should be able to whip up a two line factory ... hell, we can provide some code to do it automatically (and run it on the Lucene jar everytime we update it) what i'd really hate to see happen, is to need a FAQ item about how "slow" Solr is at indexing docs and have the answer be: "Don't rely on the built in reflection mechanism to build you analyzers, create explicit Factories for each Tokenizer/Filter" ... I'd hate for Solr's to have reflection based Analyzer construction that winds up like the Lucene "Hits" class -- overused and the source of countless complaints about performance. Ah yes, here's the old discussion... http://www.nabble.com/foo-tf1737025.html#a4720545 -Hoss
