[jboss-dev] Bootstrap Configuration Overrides

[Jaikiran Pai]

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
>