Hi, FYI, this is the same issues like Locales have/had in ICU! If you try to render an error message in Locales's constructors, this breaks with NPE - because default Locale is not yet there... I think they implemented some "fallback" that is guaranteed to be there.
But this would not help you, too - you need the default Codec be available at the time your custom codec is loaded... Same issue, no idea how to solve this. 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:ben...@basistech.com] > Sent: Thursday, February 12, 2015 11:34 AM > To: java-user@lucene apache. org > Subject: Re: A codec moment or pickle > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
