Re: [infinispan-dev] Standardising on property names and system parameters

That's fine by me. One quick note: infinispan.server.cache_config in Main.scala would become infinispan.server.cfg, the same property for the REST server.

program.name can really go away. I think i copy/pasted from gnu getopt code examples I used. Basically, the program name is used by getopt to show it when printing errors. It could simply be hardcoded without any problems. How shall we go about implementing this? Each looks at their own classes? Or one does it all? I think the latter might be easier to achieve.

Thanks Manik for looking into this. On Jul 8, 2010, at 4:55 PM, Manik Surtani wrote: > Guys, > > I have seen a number of places in the codebase where we take in system parameters. In some cases this is to control certain unit test options such as: > > http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/jdbc/src/test... > http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/cloud/src/int... > http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/i... > > And in some cases these control runtime options such as: > > http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... > http://fisheye.jboss.org/browse/Infinispan/trunk/server/rest/src/main/sca... > http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca... > > And we occasionally use Properties to configure certain bits, such as certain Hot Rod and Memcached server options: > > http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca... > > And even Hot Rod client configs. > > http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src... > > And here are some examples of what the keys to these properties are: > > infinispan.jclouds.username > infinispan.jdbc > infinispan.tm > infinispan.config.schema > infinispan.server.rest.cfg > program.name > infinispan.server.host > infinispan.hotrod-client.servers-default > > I would like to standardise on these a bit. It would (a) make it easier to document and (b) provide a greater level of consistency. So here is what I propose: > > * All system and property keys start with "infinispan." > * Properties destined to control the way the test suite runs should have ".test." > * The next bit should be the relevant affected module. E.g., ".server.hotrod." or ".server.rest." or ".client.hotrod.", or ".server." for stuff that is common across all server endpoints. > * and the last bit could be descriptive to what the key controls. E.g., ".host". > > So, from above, the examples would look like: > > infinispan.test.cachestore.jclouds.username > infinispan.test.cachestore.jdbc.driver > infinispan.test.core.tm > infinispan.core.config.schema > infinispan.server.cfg > (program.name? Don't know what this is... ) > infinispan.server.host > infinispan.client.hotrod.servers > > What do you guys think? If we agree on this, this would involve: > > 1) Read the correct, new property > 2) Still read the "legacy" property but spit out a warning > 3) Update READMEs, javadocs, sample scripts, and wikis/FAQs. > > and then we would need to stick with this convention for all future stuff. > > Thoughts? > > Cheers > Manik > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev