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