[
https://issues.apache.org/jira/browse/SOLR-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997619#comment-16997619
]
Robert Muir commented on SOLR-14100:
------------------------------------
upgrading to the latest version of the software doesn't fix that either. It
seems its just typical reasons why i hate Java: why call
System.getProperty("xyz") when you can do something super-elaborate with
utility methods, maps, enums, etc?
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/ConsoleAppender.java#L76
> System properties cross test suite boundary
> -------------------------------------------
>
> Key: SOLR-14100
> URL: https://issues.apache.org/jira/browse/SOLR-14100
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Major
>
> At some point in time all system properties were saved/ restored in the top
> test class. When security manager was added (a long time ago) as the default
> this has been turned off (because the rule couldn't read all properties then)
> and replaced with just a selected subset of properties to be checked (in
> LuceneTestCase). Sadly, Solr's security policy allows all properties to be
> written and I bet this also leads to complex interactions between tests.
> We can allow read access to all properties at first but all writeable/
> modifiable properties should be identified and added to a top-level restore
> rule, along with security manager policy that selectively enables them (so
> that we know they're saved and restored after each test).
> This is going to be a tedious task.
--
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
