First off - nice job, these constants should have been available a long time ago!
One question a couple of comments: 1) Is the idea with the change that all code should reference the constants in DistributedSystemConfigProperties. For example, I should use DistributedSystemConfigProperties.CACHE_XML_FILE when writing a test, rather than DistributionConfig.CACHE_XML_FILE? In that case, maybe DistributionConfig should not extend DistributedSystemConfigProperties? 2) Add @since Geode 1.0 to this interface, as well as some javadocs describing to users what's contained in this interface. 3) DistributedSystem has a ton of javadocs describing each property and what it does. I wonder if those javadocs should move to the constants in this interface instead? -Dan On Wed, Jun 1, 2016 at 5:17 PM, Udo Kohlmeyer <[email protected]> wrote: > Hi there, > > As per GEODE-1377 <https://issues.apache.org/jira/browse/GEODE-1377> I've > refactored DistributionConfig to extract all public system properties into a > public DistributedSystemConfigProperties interface. > > With that refactor I've touched a significant amount of classed and I, in > advance, apologize for the merging. > > I've have tried to find all references to all the properties that we use > within Geode (be it main and test). > > For future development, if we are to use and system properties, that we use > the provided definition for that property. That will help us to understand > where the properties are used and will make it easier if we need to refactor > anything in the future. > > I've also tried to find every reference to "gemfire." and replaced it with > its defined counterpart. This should hopefully help us if we were to move > away from property definitions like "gemfire.locators" to "geode.locators". > If someone were to find that I had missed an obvious property to please > refactor and resolve that issue. > > In addition to this effort I have noticed that we use a large amount of > properties to configure functionality. I respectfully request from all > developers that if you were to work on some code that uses "internal" > properties to maybe pull it out into a common interface which can be reused > throughout the code base. > > --Udo > >
