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).
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> 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> 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