Honestly i dont agree. I don't know what you are trying to do, but if you want file format backwards compat working, then you need a different FilterCodec to match each lucene codec.
Otherwise your codec is broken from a back compat standpoint. Wrapping the latest is an antipattern here. On Thu, Feb 12, 2015 at 5:33 AM, Benson Margulies <ben...@basistech.com> wrote: > 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
