Erick Erickson created SOLR-14793:
-------------------------------------
Summary: 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
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: [email protected]
For additional commands, e-mail: [email protected]
