Deprecations and SolrConfig patch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecations and SolrConfig patch

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



Reply | Threaded
Open this post in threaded view
|

Re: Deprecations and SolrConfig patch

Ryan McKinley

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



Reply | Threaded
Open this post in threaded view
|

Re: Deprecations and SolrConfig patch

hossman

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

Reply | Threaded
Open this post in threaded view
|

Re: Deprecations and SolrConfig patch

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