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

[Manik Surtani]

Note that this thread covers not just system properties, but also any other subsystem configured using a .properties file or a Properties instance (such as the HotRod client).

As far as System properties are concerned, I agree they are evil but lets look at where System properties are used.

1.  control the way the test suite runs.  
2.  disable schema validation when reading the config XML
3.  override config file to read Infinispan config from

For each of these, I think it is okay to use System properties.  1 is fine, it's just to control the test suite.  And 2 and 3 would have to be System properties as it controls how the rest of the config is read.  Any use of System properties *other than* these 3 cases should be carefully considered, and probably removed in favour of other techniques.

WDYT?

Cheers
Manik

On 9 Jul 2010, at 11:03, Galder Zamarreño wrote:

> In what way?
> 
> As far as Infinispan server's are concerned, most of the uses there are just a way to alternatively pass command line parameters such as cache configuration file...etc. Note that this is not documented in any wiki yet, so if we're gonna remove them, this could be a good time to do so.
> 
> In the case of the REST server though, since this is a WAR, we can't pass a command line parameter, so I think we really need a system property here.
> 
> I don't see any probs with using system properties in testing.
> 
> On Jul 9, 2010, at 10:27 AM, Emmanuel Bernard wrote:
> 
>> I'd strongly advise to not use system properties. It's something we suffer from in Hibernate and wished we had not introduced. 
>> 
>> On 8 juil. 2010, at 16:55, Manik Surtani <manik at jboss.org> 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/java/org/infinispan/test/fwk/UnitTestDatabaseManager.java?r=1957#l53
>>> 	http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/cloud/src/integrationtest/java/org/infinispan/loaders/cloud/CloudCacheStoreFunctionalIntegrationTest.java?r=1845#l46
>>> 	http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/infinispan/test/fwk/TransactionSetup.java?r=722#l46
>>> 
>>> And in some cases these control runtime options such as:
>>> 
>>> 	http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/infinispan/config/InfinispanConfiguration.java?r=1951#l362
>>> 	http://fisheye.jboss.org/browse/Infinispan/trunk/server/rest/src/main/scala/org/infinispan/rest/StartupListener.scala?r=1863#l33
>>> 	http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/scala/org/infinispan/server/core/Main.scala?r=1954#l169
>>> 
>>> 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/scala/org/infinispan/server/core/AbstractProtocolServer.scala?r=1898#l24
>>> 
>>> And even Hot Rod client configs.
>>> 
>>> 	http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/RemoteCacheManager.java?r=1999#l167
>>> 
>>> 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 at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org