I propose that solr-tests.policy (the Java SecurityManager configuration we use for tests) shouldn't impose restrictions beyond the file system. Ensuring tests don't write all over the file system is important, and this has been the foundation for Solr's tests using the Java SecurityManager in the first place.
But all the other restrictions seem pointless and are a burden to maintain. Notably, we're adding a new JDK HttpClient based SolrClient and now we have to go adding a whole bunch of rules to the test policy: https://github.com/apache/solr/blob/ff32ed020ab80c61c3ab83ee1ad5bcee61c1ebcd/gradle/testing/randomization/policies/solr-tests.policy I've been burdened by this in the past, though I forget the specifics. And as you should all know, the whole SecurityManager is deprecated as well; which suggests a direction of reducing code/support burden in this arena, especially for tests, is fine. Any concerns here? The only reason I can think of to keep the status quo is for testing that the production policy is adequate, which is somewhat kept in sync with the test policy. I think integration tests (e.g. bats) address some of that but admittedly it may not be enough to cover every single rule we have. At least it's merely configuration, and thus is user configurable even if awkward. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
