[
https://issues.apache.org/jira/browse/SOLR-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dodsworth resolved SOLR-3017.
-------------------------------------
Resolution: Fixed
Yonik's fix resolves this. Much appreciated.
> Allow edismax stopword filter factory implementation to be specified
> --------------------------------------------------------------------
>
> Key: SOLR-3017
> URL: https://issues.apache.org/jira/browse/SOLR-3017
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.0
> Reporter: Michael Dodsworth
> Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3017-without-guava-alternative.patch,
> SOLR-3017.patch, SOLR-3017.patch, edismax_stop_filter_factory.patch
>
>
> Currently, the edismax query parser assumes that stopword filtering is being
> done by StopFilter: the removal of the stop filter is performed by looking
> for an instance of 'StopFilterFactory' (hard-coded) within the associated
> field's analysis chain.
> We'd like to be able to use our own stop filters whilst keeping the edismax
> stopword removal goodness. The supplied patch allows the stopword filter
> factory class to be supplied as a param, "stopwordFilterClassName". If no
> value is given, the default (StopFilterFactory) is used.
> Another option I looked into was to extend StopFilterFactory to create our
> own filter. Unfortunately, StopFilterFactory's 'create' method returns
> StopFilter, not TokenStream. StopFilter is also final.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]