Deprecations and SolrConfig patch

[Mike Klaas <mi...@gmail.com>]

The SolrConfig patch changed the interface for creating a token  
filter factory:

   @Deprecated
   public void init(Map<String,String> args) {
     log.warning("calling the deprecated form of init; should be  
calling init(SolrConfig solrConfig, Map<String,String> args)");
     this.args=args;
   }

The analyzer creation chain now calls   public void init(SolrConfig  
solrConfig, Map<String,String> args)  instead.

This is very bad from a backward compatibility point of view.  For  
most extensions, their analyzers will just stop working in mysterious  
ways (since they will not get the correct parameters).  The above log  
WARNING will not be generated, because that method is not called by  
Solr.  The only hint that something is amiss is

     [javac] Note: XXFilterFactor.java uses or overrides a deprecated  
API.

which should not be an indication that the code in question will not  
function correctly.  Also, there isn't a peep of warning in CHANGES.txt

The problem seems to stem from leaving in the old method.  Since we  
are breaking backward compatibility, it would be better to break hard  
and prevent Solr from compiling, or to actually provide backward  
compatiblity.

grumpy,
-Mike

Re: Deprecations and SolrConfig patch

[Ryan McKinley <ry...@gmail.com>]

> 
> being offline and out of hte loop for a few days has left me a little 
> confused as to what exactly the imcompatibility is ... could someone open 
> an issue summarizing the problem and mark it fix for 1.3 .. that way we'll 
> have a reminder to either get a fix in, or document the hell out of it as 
> a known incompatibility (which would suggest 1.3 be renamed 2.0, but i'm 
> not sure how neccessary that is without a better understanding of how bad 
> the incompatibility is)
> 

To the best of my knowledge, the problem Mike ran into is now fixed in 
trunk.

The basis issue was that the deprecation handling that Henri built into 
SOLR-215 for TokenFilterFactory and BaseTokenizerFactory worked if an 
existing custom XXXFactory did not extend the BaseXXXFactory since the 
BaseXXXFactory did not call the now deprecated  init(Map<String,String> 
args) method.

I will resolve SOLR-215 now and any problems that arise from it should 
get their own new issue.

ryan

Re: Deprecations and SolrConfig patch

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

: > which should not be an indication that the code in question will not
: > function correctly.  Also, there isn't a peep of warning in CHANGES.txt

: I was waiting for SOLR-360 to add the CHANGES.txt for multi-core related
: things.  You are right, the deprecated API deprecations and alternatives need
: to go in ASAP.

we should try to make notes in CHANGES.txt in the same commit as the 
changes themselves ... that way people doing their own builds can get an 
accurate idea of what's changed by diffing the file ... rough 
descriptions of changes that we plan on cleaning up later are better then 
no description.

: I think there is a way to maintain backward compatibility, but it is not
: totally straightforward (so i can't do it right now)

being offline and out of hte loop for a few days has left me a little 
confused as to what exactly the imcompatibility is ... could someone open 
an issue summarizing the problem and mark it fix for 1.3 .. that way we'll 
have a reminder to either get a fix in, or document the hell out of it as 
a known incompatibility (which would suggest 1.3 be renamed 2.0, but i'm 
not sure how neccessary that is without a better understanding of how bad 
the incompatibility is)



-Hoss

Re: Deprecations and SolrConfig patch

[Ryan McKinley <ry...@gmail.com>]

Check my last comment on SOLR-215

> 
> which should not be an indication that the code in question will not 
> function correctly.  Also, there isn't a peep of warning in CHANGES.txt
>

I was waiting for SOLR-360 to add the CHANGES.txt for multi-core related 
things.  You are right, the deprecated API deprecations and alternatives 
need to go in ASAP.


> The problem seems to stem from leaving in the old method.  Since we are 
> breaking backward compatibility, it would be better to break hard and 
> prevent Solr from compiling, or to actually provide backward compatiblity.
> 
> grumpy,
> -Mike
> 

I think there is a way to maintain backward compatibility, but it is not 
totally straightforward (so i can't do it right now)

Sorry this caused you head banging and thanks for (unwhittingly) helping 
to iron out SOLR-215.

ryan