[jira] [Comment Edited] (SOLR-14100) System properties cross test suite boundary

["Dawid Weiss (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004275#comment-17004275 ] 

Dawid Weiss edited comment on SOLR-14100 at 12/27/19 5:07 PM:
--------------------------------------------------------------

Right. This needs to be cleaned up. I compiled a list of all properties accessed (read/written/cleared) during a linux and Windows run. Like Robert pointed out it's an insanely long list and contains bugs already (typos).

A way to follow would be to:
1) limit write access to those identified properties that need it (allow reading all props, like in Lucene),
2) identify third-party library offenders that require full-write accesses and perhaps fix them in those projects (?).
3) add a top-level restore rule with the same list (so that we can ensure all properties are restored after each test),
4) review this insane list and remove bugs and unnecessary write accesses whenever possible.

3 and 4 can be done independently and it'd already be an improvement because even if we have full write access we can consistently restore properties that have been changed.

The only problem I see for now is that Solr security policy is currently in {{server/etc/security.policy}}. This list of "writeable" properties includes many that are only used in tests and it seems inelegant to pollute production policy file with all of them... 




was (Author: dweiss):
Right. This needs to be cleaned up. I compiled a list of all properties accessed (read/written/cleared) during a linux and Windows run. Like Robert pointed out it's an insanely long list and contains bugs already (typos).

A way to follow would be to:
1) limit write access to those identified properties that need it (allow reading all props, like in Lucene),
2) add a top-level restore rule with the same list (so that we can ensure all properties are restored after each test),
3) review this insane list and remove bugs and unnecessary write accesses whenever possible.

The only problem I see for now is that Solr security policy is currently in {{server/etc/security.policy}}. This list of "writeable" propertiesa includes many that are only used in tests and it seems inelegant to pollute production policy file with all of them... 



> 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
>         Attachments: SOLR-14100_hack.patch, props-reads.log, props-writes.log
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org