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 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
