Assuming "Configuratrion property" means a property specified in a some
configuration file, IMO the following rules could be used:
Object model (takes precedence over) -> Config property (takes
precedence over) -> System Property (takes precedence over) ->
Environment variable.
This precedence order would allow:
1) Object model to override the property set either at
config/system/environment level. Thus, config.setJBossHome("mytesthome")
can be used within some specific testcase.
2) Config property to override the property set at system/environment
level. Thus allowing an application to set these as "application
specific" properties and let other applications use the
system/environment level values.
3) System property to override environment level. Thus allowing
different JVMs on the same system to use their own values.
4) The Environment variable will have the lowest precedence.
Thoughts?
-Jaikiran
Andrew Lee Rubinger wrote:
I'm in the process of reforming the JBossAS Configuration within
the
Bootstrap Project.
Each configuration property may come from:
* Object model
ie. config.getJBossHome()
* System property
ie. -Djboss.home=/myJBossHome
* Configuration property
ie. config.getProperty("jboss.home")
* Environment Variable
(optional, ie. $JBOSS_HOME)
What do we think the order of preference should be in determining
which value is authoritative? I'm thinking the following rules:
System Property > Configuration Property > Object Model > Environment
Variable
...this means that anything may be overridden from the command line.
Environment variable comes last as it may be used to fall back on some
default. In truth all system properties get dumped into the
configuration properties upon config creation, so system props is a
subset of config props (more may be programmatically added to config
props after config creation).
If at the end of this chain a property is still unspecified, we'll set
it to some intelligent default, following a "convention over
configuration" paradigm.
Thoughts?
S,
ALR