Seeking Feedback: non back compat for Java API of 3 FilterFactories in 1.3?

[Chris Hostetter <ho...@fucit.org>]

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

Re: Seeking Feedback: non back compat for Java API of 3 FilterFactories in 1.3?

[Walter Underwood <wu...@netflix.com>]

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" <ho...@fucit.org> 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
>