We should definitely have default values to run out of the box. There should be zero friction to use the system after installation.
Maybe it is a good idea to set all the properties in the Guice Module and use the properties file to override them. In that way, we can ship with a default Module that runs something like a cluster with 2 nodes on the local host. We should still include the properties file with the properties commented out. One problem is that we need to maintain properties in two places (properties file and Guice Module) which is error prone and cannot be verified in unit tests. BTW, the properties class has methods to read properties and use defaults if the property doesn't exist. The problem is the typos that will result in errors. The other option is to not have properties file and define everything in the Guice Module. This solves the inconsistency but requires code changes to change props. On the other hand I see the properties file as another source file, that's the whole point of using Guice: not to be afraid to use Java static typing for configuration. So basically, I am not answering your question :-) -leo On Fri, Jan 6, 2012 at 10:18 PM, Karthik Kambatla <[email protected]> wrote: > We have several configuration parameters in our code base, which we are > currently supplying through our modules. It would be nice if we set default > values for these parameters, so that the user need not go through every > gory detail before running their apps. How can we go about it? > > 1. Using Guice, set default values for these parameters in the code base > itself - don't know how to go about it yet. > 2. I like the hadoop approach - where they have default-<>.xml and > site-<>.xml. Parameters specified in the site xml override those mentioned > in the default. > > Should we take any of these routes, or should we just leave it for now? If > you guys think it is important enough, I can create a JIRA for the same. > > Thanks > Karthik -- Leo Neumeyer (@leoneu)
