[infinispan-dev] Standardising on property names and system parameters
Manik Surtani
manik at jboss.org
Fri Jul 9 06:05:16 EDT 2010
On 9 Jul 2010, at 09:00, Galder Zamarreño wrote:
> 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.
Sure, I just put up infinispan.server.cfg as an example. We could use either, we just need to stick to one.
> 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.
Probably the latter. I can take this on if you want, I'll create a summary and post it here before I commit any changes.
>
> 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/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
>
> --
> 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
More information about the infinispan-dev
mailing list