[
https://issues.apache.org/jira/browse/SOLR-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590020#action_12590020
]
Grant Ingersoll commented on SOLR-515:
--------------------------------------
I'd suggest we seriously start thinking about Spring and stop recreating yet
another Web Framework! All these workarounds to make Solr some pseudo IOC
container make my head hurt. All this initialization stuff has been solved so
nicely in Spring that we could gut out all of this complicated stuff and just
focus on creating a less complicated Solr with more search capabilities and
less in the way of initialization capabilities. I honestly can't keep my head
straight anymore between Loaders, CoreAware, InitializedPlugin, inform(),
init() etc.
> SimilarityFactory patch: facilitate parameterizable Similarity implementations
> ------------------------------------------------------------------------------
>
> Key: SOLR-515
> URL: https://issues.apache.org/jira/browse/SOLR-515
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Erik Hatcher
> Assignee: Erik Hatcher
> Fix For: 1.3
>
> Attachments: similarity_factory.patch, similarity_factory.patch,
> similarity_factory.patch
>
>
> Solr currently allows a pluggable Lucene Similarity to be specified as:
> <similarity class="org.apache.lucene.search.DefaultSimilarity"/>
> This patch does not change this syntax at all, but detects whether a
> Similarity or a SimilarityFactory is specified. The new SimilarityFactory
> class passes a NamedList from the config file into a getSimilarity(NamedList)
> method.
> Yes, I used an interface, damn it! Let the battles continue. I've spoken
> with my code on the issue. But sure, I'll acquiesce on the topic and turn it
> into an abstract class if I must - stupid programming languages!
> object-oriented programming, not interface or abstract oriented programming
> :) All I ask is ya show me a good case where this interface won't suit your
> needs, and I'll reply that instead of thinking the problem is the interface,
> consider it is how the interface is used - it's implicitly designed to be
> simply that, an interface. You want a different way to configure, don't like
> NamedLists for some reason maybe?, we change IndexSchema Similarity
> construction smarts, perhaps creating another interface. Same diff, sort of.
> I'm proud of the unit test, no XPath in sight.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
