Re: Avoid mutating standard Java System Properties (even in tests)

There is no issue with setting GemFire-specific System Properties. Feel free to use those. I'm talking about changing the values of System Properties set by the JVM such as "user.dir" -- mutating or clearing these values can cause weird bugs in the JDK or 3rd party libraries that are harder to debu

Re: Avoid mutating standard Java System Properties (even in tests)

Come on guys, it's 2017 and we should not still be talking about using system properties at all. I won't rant again about our prolific use of system properties but I will rant on the testing using them. Unless your test is a unit test that is asserting that your component picks up its initial state

Re: Avoid mutating standard Java System Properties (even in tests)

I have had a lot of tests fail because mcast-port is nonzero. So now I set that system property in a lot of new tests. Maybe the tests that set it to something other than the default should be passing a Properties object to CacheFactory rather than messing with system properties. I think the Cache

Re: Avoid mutating standard Java System Properties (even in tests)

Indeed, this is frowned upon by the JDK authors: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4045688 In the long term, we need to change our code to no longer assume that “user.dir” is the working directory of a given server/

Re: Avoid mutating standard Java System Properties (even in tests)

Oops. Correction on #3: Looks like the caller of ManagementAdapter#handleCacheCreation(InternalCache) DOES log any caught exceptions. But because the test uses a log-file that lives in a JUnit TemporaryFolder, we have no visibility of the logged exception after the test completes. This is one time