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

On 8 Jul 2010, at 16:00, Manik Surtani wrote: > Sorry, one more that I intended to demonstrate: > > http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src... > > marshaller.default-array-size.key > > should look like: > > infinispan.client.hotrod.marshaller.key-array-init-size > > or something like that. That's not passed in as a System property, but guess it will go away anyway with the new marshalling stuff

On 9 Jul 2010, at 12:40, Manik Surtani wrote: > > On 9 Jul 2010, at 12:36, Mircea Markus wrote: > >> >> On 8 Jul 2010, at 16:00, Manik Surtani wrote: >> >>> Sorry, one more that I intended to demonstrate: >>> >>> http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src... >>> >>> marshaller.default-array-size.key >>> >>> should look like: >>> >>> infinispan.client.hotrod.marshaller.key-array-init-size >>> >>> or something like that. >> That's not passed in as a System property, but guess it will go away anyway with the new marshalling stuff > > It is not a system property, but rather a config element in the hotrod-client.properties file. > > And it would still be there, even after ISPN-532 as a hint to key and value size to optimise byte array allocation as you suggested in the thread related to Hot Rod's client marshaller. Wouldn't prepending all the props in hotrod-client.properties with infinispan.client reduce readability? There's no chance for conflict.

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

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(a)jboss.org&gt; 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.org&gt; 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 > > _______________________________________________ > 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

On Jul 9, 2010, at 2:09 PM, Emmanuel Bernard wrote: > By using a system property, whatever you configures can only be set once per vm. > So say your server could only be run once per vm. You could avoid that simply by using the war/servlet approach of defining application-scoped properties (web.xml). The use of system properties in the servers is limited to the Main class which contains the main method. Hence, using system properties there it's fine cos there can only be one main method run in a VM. You can start multiple servers in a VM programatically without the need of setting any system properties cos Main class should not be used in these cases. For the REST server though, I agree that we should prob stop using system property and have an env-entry instead. (https://jira.jboss.org/browse/ISPN-537) > > Also system properties are hell to setup for operation people, they need to hack whatever run.sh script to set things up on each deployment. > It also has potentially unexpected side effect when you deploy app2 next to app1 and all of the sudden it behaves differently than if you deploy it next to app3. > > Embedded runtime is quite en vogue, you're cutting yourself from that as well. > > For your test suite, do whatever you want , it's your problem, it's not exposed to your users :) > > On 9 juil. 2010, at 12:03, Galder Zamarreño <galder(a)redhat.com&gt; 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(a)jboss.org&gt; 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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

As discussed in the list, I think the REST startup listener shouldn't use a system property from now on, see https://jira.jboss.org/browse/ISPN-537. The old system property should be supported but onwards, it should use an env entry.

Why do protocol.stack and infinispan.tm need support for original key? Is it due these having been documented already?

On Jul 13, 2010, at 5:23 PM, Manik Surtani wrote: > Here is an analysis of all properties accessed in Infinispan, via System.properties, .properties files and via Properties objects. Please have a look at this summary and share your thoughts on proposed alternatives, etc. > > http://spreadsheets.google.com/pub?key=0AvSkuK8dhcSCdEFidUlFdkpXaWhwVXlHa... > > In general this should adhere to the naming scheme I suggested below, as well as the policy of what is and is not allowed to be a System property. If we are happy with this, I will go ahead and patch trunk and branch/4.1.x and then start on the painful process of finding references in our docs and the slightly less painful process of updating them. :) > > Cheers > Manik > > > > On 12 Jul 2010, at 11:22, Galder Zamarreño wrote: > >> >> On Jul 9, 2010, at 2:09 PM, Emmanuel Bernard wrote: >> >>> By using a system property, whatever you configures can only be set once per vm. >>> So say your server could only be run once per vm. You could avoid that simply by using the war/servlet approach of defining application-scoped properties (web.xml). >> >> The use of system properties in the servers is limited to the Main class which contains the main method. Hence, using system properties there it's fine cos there can only be one main method run in a VM. You can start multiple servers in a VM programatically without the need of setting any system properties cos Main class should not be used in these cases. >> >> For the REST server though, I agree that we should prob stop using system property and have an env-entry instead. (https://jira.jboss.org/browse/ISPN-537) >> >>> >>> Also system properties are hell to setup for operation people, they need to hack whatever run.sh script to set things up on each deployment. >>> It also has potentially unexpected side effect when you deploy app2 next to app1 and all of the sudden it behaves differently than if you deploy it next to app3. >>> >>> Embedded runtime is quite en vogue, you're cutting yourself from that as well. >>> >>> For your test suite, do whatever you want , it's your problem, it's not exposed to your users :) >>> >>> On 9 juil. 2010, at 12:03, Galder Zamarreño <galder(a)redhat.com&gt; 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(a)jboss.org&gt; 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > -- > 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