Based on reading the same comments you read, I'm pretty doubtful that
Codec.getDefault() is going to work. It seems to me that this
situation renders the FilterCodec a bit hard to to use, at least given
the 'every release deprecates a codec' sort of pattern.



On Thu, Feb 12, 2015 at 3:20 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> Hi,
>
> How about Codec.getDefault()? It does indeed not necessarily return the 
> newest one (if somebody changes the default using Codec.setDefault()), but 
> for your use case "wrapping the current default one", it should be fine?
>
> I have not tried this yet, but there might be a chicken-egg problem:
> - Your codec will have a separate name and be listed in META-INF as service 
> (I assume this). So it gets discovered by the Codec discovery process and is 
> instantiated by that.
> - On loading the Codec framework the call to codec.getDefault() might get in 
> at a time where the codecs are not yet fully initialized (because it will 
> instantiate your codec while loading the META-INF). This happens before the 
> Codec class is itself fully statically initialized, so the default codec 
> might be null...
> So relying on Codec.getDefault() in constructors of filter codecs may not 
> work as expected!
>
> Maybe try it out, was just an idea :-)
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -----Original Message-----
>> From: Benson Margulies [mailto:bimargul...@gmail.com]
>> Sent: Thursday, February 12, 2015 2:11 AM
>> To: java-user@lucene.apache.org
>> Subject: A codec moment or pickle
>>
>> I have a class that extends FilterCodec. Written against Lucene 4.9, it uses 
>> the
>> Lucene49Codec.
>>
>> Dropped into a copy of Solr with Lucene 4.10, it discovers that this codec is
>> read-only in 4.10. Is there some way to code one of these to get 'the default
>> codec' and not have to chase versions?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to