[
https://issues.apache.org/jira/browse/LUCENE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2804:
-------------------------------
Attachment: LUCENE-2804.patch
Patch fixes all tests to use newDirectory() or newFSDirectory(), except for
backwards test code. Also some improvements to LuceneTestCase are included (in
the scope of the issue).
All tests pass.
Note that I had to impl setLockFactory by FSDirectory, which caused the
addition of "throws IOException" to Directory.setLockFactory. The changes in
the issue revealed an inconsistency we had - previously if you "new
FSDirectory(File, LockFactory)" or "new FSDirectory(File).setLockFactory" you
wouldn't get the same behavior. The former set the lockPrefix to null while the
latter didn't. The changes in the patch uncovered that (TestLockFactory) and so
I made the change.
While technically this is a backwards break, I think adding that 'throws' stuff
to Directory is safe. Kinda hard to believe someone has code which calls
dir.setLockFactory and does not handle/throw IOException. I spelled it out in
CHANGES.
> check all tests that use FSDirectory.open
> -----------------------------------------
>
> Key: LUCENE-2804
> URL: https://issues.apache.org/jira/browse/LUCENE-2804
> Project: Lucene - Java
> Issue Type: Test
> Reporter: Robert Muir
> Attachments: LUCENE-2804.patch
>
>
> In LUCENE-2471 we were discussing the copyBytes issue, and Shai and I had a
> discussion about how we could prevent such bugs in the future.
> One thing that lead to the bug existing in our code for so long, was that it
> only happened on windows (e.g. never failed in hudson!)
> This was because the bug only happened if you were copying from
> SimpleFSDirectory, and the test used FSDirectory.open
> Today the situation is improving: most tests use newDirectory() which is
> random by default and never use FSDir.open,
> it always uses SimpleFS or NIOFS so that the same random seed will reproduce
> across both windows and unix.
> So I think we need to review all uses of FSDirectory.open in our tests, and
> minimize these.
> In general tests should use newDirectory().
> If the test comes with say a zip-file and wants to explicitly open stuff from
> disk, I think it should open the contents with say SimpleFSDir,
> and then call newDirectory(Directory) to copy into a new "random"
> implementation for actual testing. This method already exists:
> {noformat}
> /**
> * Returns a new Dictionary instance, with contents copied from the
> * provided directory. See {...@link #newDirectory()} for more
> * information.
> */
> public static MockDirectoryWrapper newDirectory(Directory d) throws
> IOException {
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
