RFC Title
To be Reviewed By: October 26, 2020
Authors: Dale Emery
Status: Draft | Discussion | Active | Dropped | Superseded
Superseded by: N/A
Related: N/A
Problem
Numerous Geode classes resolve relative file paths against the JVM’s working directory—the value of the user.dir
system property. Some classes do this explicitly, by resolving paths against the value of user.dir
. Other classes refer to the JVM’s working directory indirectly, either by using relative paths or by resolving paths against “.”
or “”
.
Resolving files against the JVM’s working directory makes it impossible to test many Geode features in parallel outside of a container.
Every Gradle test worker JVM for a given task type (e.g. distributedTest) has the same working directory. When tests run in parallel outside of a container, if multiple tests write to the same file path relative to the JVM’s working directory, those tests all write to the same file. The tests interfere with each other's files, causing swarms of failures.
Anti-Goals
None identified.
Solution
Make Geode resolve relative paths against a configurable path defined by a new geode.working-dir
system property.
Instead of accessing the property directly, Geode code will get the working directory from a new WorkingDirectory
class, by calling static methods that return the working directory as a java.nio.file.Path
or a java.io.File
. To maintain Geode’s current behavior, these methods return the value of user.dir
if geode.working-dir
is not set.
Optionally (TBD): These methods can ensure that the returned path is canonical (as defined by the java.io.File
documentation) and that it refers to an existing directory.
Changes and Additions to Public Interfaces
This proposal adds a new public system property: geode.working-dir
.
Any documentation that refers to user.dir
will need to refer instead to geode.working-dir
.
Any assumptions made by shell scripts that ship with Geode will have to account for this property.
Performance Impact
I expect that the additional cost to resolve paths to a canonical path will be minimal.
Backwards Compatibility and Upgrade Path
By default, if the new geode.working-dir
property is not set, Geode will behave as it currently does. Users who do not set this property will experience no change.
If the user specifies a geode.working-dir
other than the JVM's working directory, the effect on backward compatibility, the rolling upgrade process, and any shell scripts provided by either Geode or the user is TBD.
Prior Art
None known.
FAQ
None yet.
Errata
None yet.