[
https://issues.apache.org/jira/browse/SOLR-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997611#comment-16997611
]
Dawid Weiss commented on SOLR-14100:
------------------------------------
Correct, Rob. Didn't think of getProperties() being called everywhere...
indeed, it's going to be a tough one. Maybe the first step would be to get rid
of the exceptions in LuceneTestCase and just add a new rule under Solr base
class -- since Solr is allowed access to all properties that rule could take
care of restoring pristine state of system properties for Solr tests.
> 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
