[jira] Updated: (LUCENE-2804) check all tests that use FSDirectory.open

["Shai Erera (JIRA)" <ji...@apache.org>]

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org