lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: A codec moment or pickle
Date Thu, 12 Feb 2015 13:56:28 GMT
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: uwe@thetaphi.de


> -----Original Message-----
> From: Benson Margulies [mailto:benson@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 <uwe@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: uwe@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Benson Margulies [mailto:bimargulies@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org


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


Mime
View raw message