I found another problem. Maybe something changed in the logic of FSDirectory.open(), but now when I run some tests over my code, I see that if MMapDirectory is chosen and an attempt to seek to an incorrect position is made, IllegalArgumentException is thrown, instead of IOE. This breaks my code which catches IOE and handle it.
While I can modify my code to also catch IAE, I wonder if it's ok that MMapDir throws such an exception instead of IOE. It's actually thrown from ByteBuffer, however the caller, which holds a reference to a Directory, does not know if the underlying impl is MMapDir, LinuxFSDir etc. Should we fix it on the new branch and go for a second RC? Shai On Tue, Mar 8, 2011 at 9:19 AM, Shai Erera <ser...@gmail.com> wrote: > I found what seems to be a "glitch" in StopFilter's ctors -- the boolean > 'enablePosInc' was removed from the ctors and users now have to use the > setter instead. However, the ctors do default to 'true' if the passed in > Version is onOrAfter(29). > > All of FilteringTokenFilter sub-classes include the enablePosIncr in their > ctors, including FilteringTF itself. Therefore I assume the parameter was > mistakenly dropped from StopFilter's ctors. Also, the @deprecated text > doesn't mention how should I enable/disable it, and reading the source code > doesn't help either, since the setter/getter are in FilteringTF. > > Also, LengthFilter has a deprecated ctor, but the class was added on Nov 16 > and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add a > @since tag to the class)? > > I don't know if these two warrant a new RC but I think they are important > to fix. > > Shai > > > On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. <dsmi...@mitre.org>wrote: > >> So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in >> yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited >> for a committer to agree with the issue. I would have had it in Saturday. >> >> ~ David Smiley >> >> On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: >> >> > Hi all, >> > >> > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, >> > both from revision 1078688 of >> > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ >> > Thanks for all your help! Please test them and give your votes, the >> > tentative release date for both versions is Sunday, March 13th, 2011. >> > Only votes from Lucene PMC are binding, but everyone is welcome to >> > check the release candidates and voice their approval or disapproval. >> > The vote passes if at least three binding +1 votes are cast. >> > >> > The release candidates are produced in parallel because in 2010 we >> > merged the development of Lucene and Solr in order to produce higher >> > quality releases. While we voted to reserve the right to release >> > Lucene by itself, in my opinion we should definitely try to avoid this >> > unless absolutely necessary, as it would ultimately cause more work >> > and complication: instead it would be far easier to just fix whatever >> > issues are discovered and respin both releases again. >> > >> > Because of this, I ask that you cast a single vote to cover both >> > releases. If the vote succeeds, both sets of artifacts can go their >> > separate ways to the different websites. >> > >> > Artifacts are located here: http://s.apache.org/solrcene31rc0 >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >
