[jira] [Resolved] (SOLR-14793) Clean up tests that log access permission violations.

["Erick Erickson (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-14793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson resolved SOLR-14793.
-----------------------------------
    Resolution: Invalid

Somehow I thought there were only a handful of these, in which fixing them makes sense. But it turns out when I looked again there were over a thousand, so it's not worth the effort.

> Clean up tests that log access permission violations.
> -----------------------------------------------------
>
>                 Key: SOLR-14793
>                 URL: https://issues.apache.org/jira/browse/SOLR-14793
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Major
>
> I noticed that some tests generate exceptions because they try to modify a project directory. The test framework explicitly disallows this. In particular, CoreContainer  tries to create a "userFiles" path and the PackageStore c'tor superclass tries to "ensurePackageStoreDir" both under SOLR_HOME. Unless we're working from a temporary directory that the test creates, this is disallowed by the framework and the stack trace is printed.
> Yet we have to log those errors for the real world to alert users to their own permissions issues.
> I should emphasize that the tests succeed since these two exceptions are caught and a warning message is printed that some things might not work. It's just that when trying to understand a test failure, having spurious errors in the log can lead people down a rathole.
> The one example I've chased down so far is in DirectUpdateHandler, and you can get around this by something like this:
> {code:java}
>   private static void setupCore()  throws Exception {
>     final File tmpSolrHome = createTempDir().toFile();
>     final File tmpConfDir;
>     final String confDir = "collection1/conf";
>     tmpConfDir = new File(tmpSolrHome, confDir);
>     File testHomeConfDir = new File(TEST_HOME(), confDir);
>         FileUtils.copyFileToDirectory(new File(testHomeConfDir, "solrconfig.xml"), tmpConfDir);
>     FileUtils.copyFileToDirectory(new File(testHomeConfDir, "schema-tiny.xml"), tmpConfDir);
>     FileUtils.copyFileToDirectory(new File(testHomeConfDir, "solrconfig.snippet.randomindexconfig.xml"), tmpConfDir);
>     
>     initCore("solrconfig.xml", "schema-tiny.xml", tmpSolrHome.getPath());
>   }
> {code}
> Different schemas may require different files... I'll think about this if/when I tackle this. Using the minimal schema.
> Amusing problem with schema-tiny.xml. DirecUpdateHandlerTest. I couldn't understand why the test was claiming that schema-tiny.xml had the {code}_version_{code} field defined, it does not! I looked!
> Well,
> h.getCore().getLatestSchema().getFieldOrNull(VERSION_FIELD)
> actually does match {code}<dynamicField name="*" type="string" indexed="true" stored="true"/>{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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