[Commons Configuration] idea

[Tom <tb...@tbee.org>]

I have no idea if CC support this, but it's an FYI: I use a home made 
configuration class. The idea behind it is that some configuration items 
are relevant in a machine context (DB hostname?), others only for a user 
(GUI settings?), other in the combination of machine and user (home 
dir?), so this class automatically collects configuration based on the 
context it is running in. The context is determined by attributes, these 
attributes can be provided manually after instantiation, and some are 
set automatically. The class then tries to find configuration files in 
the classpath that match the current attributes.

Say you have a machine name "compA", a user "userB", it searches for:

configuration.properties
configuration#system=compA#.properties
configuration#user=userB#.properties
configuration#system=compA#user=userB#.properties

Of course the default prefix "configuration" can be altered to, for 
example, the application name.

The biggest advantage is that it is possible to check the configuration 
files into the repository. When checking it out on another system, it 
automatically uses other configuration files, so there is no 
"configuration war". Naturally it has a monitoring thread to detect 
changes, allows chaining to make configuration even more flexible, etc.

Just a FYI.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [Commons Configuration] idea

[Tom <tb...@tbee.org>]

Thanks!

> - Property selectors (or filters) allow conditional property values.
I like the conditional properties. Hmmmm. A lot even, becase it gives a 
better overview instead of separate files! So I'm going to adapt my 
class to also search for this notation style, because I want a key-value 
style:

host[system=production]=192.168...
LookAndFeel[user=pete]=metal

or better:

host[system:production]=192.168...
LookAndFeel[user:pete]=metal
homedir[system:production][user:pete]=\tmp\here

since that would be compatible with the Properties class.



> - Multienvironment: allows having different properties for different
> environments which can be selected by running the app with different
> system properties:

I think that I don't get multienvironment thingy completely, seems 
rather complex and they use "is replaced" and I don't like that. I 
prefer the bottom-up search appraoch: first try to find the definition 
in the most detailled scope, if not found then find in a lesser scope, 
etc (similar to the getAttribute in web application pages). And you need 
to explicitely include files, instead of auto search. Plus, using a 
"system=xxx" notation you can do it with conditional properties.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [Commons Configuration] idea

[Jorge Ferrer <jo...@gmail.com>]

You maybe interested in taking a look at EasyConf which is build on
top of Commons Configuration and has a couple of features similar to
what you suggest:
- Property selectors (or filters) allow conditional property values.
For example:
skin[teacher]=blue
skin[student][secundary]=green
skin[student]=yellow
skin=grey
http://easyconf.sourceforge.net/user/properties/filters.html

- Multienvironment: allows having different properties for different
environments which can be selected by running the app with different
system properties:
http://easyconf.sourceforge.net/user/properties/multienvironments.html

Cheers,
Jorge

On 6/8/06, Tom <tb...@tbee.org> wrote:
> I have no idea if CC support this, but it's an FYI: I use a home made
> configuration class. The idea behind it is that some configuration items
> are relevant in a machine context (DB hostname?), others only for a user
> (GUI settings?), other in the combination of machine and user (home
> dir?), so this class automatically collects configuration based on the
> context it is running in. The context is determined by attributes, these
> attributes can be provided manually after instantiation, and some are
> set automatically. The class then tries to find configuration files in
> the classpath that match the current attributes.
>
> Say you have a machine name "compA", a user "userB", it searches for:
>
> configuration.properties
> configuration#system=compA#.properties
> configuration#user=userB#.properties
> configuration#system=compA#user=userB#.properties
>
> Of course the default prefix "configuration" can be altered to, for
> example, the application name.
>
> The biggest advantage is that it is possible to check the configuration
> files into the repository. When checking it out on another system, it
> automatically uses other configuration files, so there is no
> "configuration war". Naturally it has a monitoring thread to detect
> changes, allows chaining to make configuration even more flexible, etc.
>
> Just a FYI.
>
> Tom
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org