Seeking Feedback: non back compat for Java API of 3 FilterFactories in 1.3?
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 MapString,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 MapString,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
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 MapString,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 MapString,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
Re: Seeking Feedback: non back compat for Java API of 3 FilterFactories in 1.3?
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 MapString,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 MapString,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
Re: Seeking Feedback: non back compat for Java API of 3 FilterFactories in 1.3?
Same here. I took a look at the options you from the dev list and seems to me (3) user education should be fine. Thanks for all the great work. Brendan On Jun 13, 2008, at 4:37 PM, Brian Johnson wrote: 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 MapString,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 MapString,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
