+1 to naming it "ConfigurationProperties" +1 to moving the javadocs
On Thu, Jun 2, 2016 at 10:46 AM, John Blum <[email protected]> wrote: > Perhaps the (interface) name can be simplified to ConfigurationProperties > too. Not all properties necessarily involve specifically the distributed > system configuration, but rather the overall Geode system configuration > (Cache, Management, HTTP Service(s), Clients, etc). > > On Thu, Jun 2, 2016 at 10:27 AM, Dan Smith <[email protected]> wrote: > > > 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 > > > > > > > > > > > > -- > -John > 503-504-8657 > john.blum10101 (skype) >
