[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
