FWIW - I have no problem with the change. Thanks,
Brian ----- Original Message ---- From: Walter Underwood <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Friday, June 13, 2008 11:38:27 AM Subject: Re: Seeking Feedback: non back compat for Java API of 3 FilterFactories in 1.3? We use it out of the box. Our extensions are new filters or new request handlers, all configured through the XML files. wunder On 6/13/08 11:15 AM, "Chris Hostetter" <[EMAIL PROTECTED]> wrote: > > The Solr Developers would like some feedback from the user community > regarding some changes that have been made to StopFilterFactory, > SynonymFilterFactory, and EnglishProterFilterFactory since Solr 1.2 which > breaks backwards compatibility in situations where client Java code > directly construction and initializes instances of these classes. > > These changes do *NOT* affect Solr users who use Solr "out of the box". > > The only people who might possibly be impacted by these changes are users > who write custom Java code using the Solr APIs and directly construct > instances (instead of getting them from an IndexSchema object) using > code such as this.... > StopFilterFactory f = new StopFilterFactory() > f.init(new Map<String,String()); > // now do something with f > > If this does not apply to you, you can safely ignore this thread. > > If this does apply to you, please review SOLR-594 and the mailing list > threads linked to from that issue and let us know (either by replying to > this thread, or by posting a comment in the Jira issue) what you think > about the proposed "solution" -- Documenting that when upgrading to Solr > 1.3, any custom code like this would need to be changed like so... > StopFilterFactory f = new StopFilterFactory() > f.init(new Map<String,String()); > f.inform(SolrCore.getSolrCore().getSolrConfig().getResourceLoader()); > // now do something with f > > Of the options available, it is our belief that this is: 1) the simplest > approach; 2) benefits the majority of users automaticly; 3) adversely > affects the fewest number of people; 4) affects those people in a > relatively small way (requiring one new line of code). But we do want > to verify that the number of people affected is in fact relatively small. > > https://issues.apache.org/jira/browse/SOLR-594 > > Thanks. > > > -Hoss >
