You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <sm...@lfjr.net> on 2004/10/20 16:51:31 UTC
[configuration] ConfigurationFactory & namespaces
While reviewing ConfigurationFactory I stumbled on the namespace logic,
may I ask who is actually using it ? It looks like an unnecessary
complexity to me, imho it's easier to have several configuration
descriptors rather than a single namespaced descriptor.
What do you think ?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] ConfigurationFactory & namespaces
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Eric Pugh wrote:
> Re: [configuration] ConfigurationFactory & namespacesI agree with everything
> excelpt the last one, merging the two.. CompositeConfiguration is a very
> simple holder for configurations. You can easily use it programatically for
> example.
Even if CompositeConfiguration had a persistence mechanism we could
still use it programatically independently of any configuration file.
I'm not convinced this is a good idea yet, I just wanted to throw it
there and discuss it.
> However, ConfigurationFactory brings a lot more with it.. Including with
> what you propose the ability to reload itself.. Something to think about
> is that if ConfigurationFactory is going to start reloading itself, then
> maybe we need to think about how we are going to bolt in out event handling
> stuff.
I haven't really started studying the event handling yet. What are the
needs ? Notify about properties added, changed or removed ? Notify about
configurations reloaded ? Should we trigger a single event with a list
of all the properties modified, or an event per property changed ? The
design choices of the [event] component in the sandbox might help us in
implementing this feature.
> On a related note, now that Vector has been removed, and you have tossed in
> a bunch of small features and stuff that had been sitting around. Should we
> think about a 1.1 release? I know, it seems soon, but... Release
> early/release often...
Hmmm once I land INIConfiguration why not.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] ConfigurationFactory & namespaces
Posted by Eric Pugh <ep...@upstate.com>.
Re: [configuration] ConfigurationFactory & namespacesI agree with everything
excelpt the last one, merging the two.. CompositeConfiguration is a very
simple holder for configurations. You can easily use it programatically for
example.
However, ConfigurationFactory brings a lot more with it.. Including with
what you propose the ability to reload itself.. Something to think about
is that if ConfigurationFactory is going to start reloading itself, then
maybe we need to think about how we are going to bolt in out event handling
stuff.
On a related note, now that Vector has been removed, and you have tossed in
a bunch of small features and stuff that had been sitting around. Should we
think about a 1.1 release? I know, it seems soon, but... Release
early/release often...
Eric
-----Original Message-----
From: Emmanuel Bourg [mailto:smanux@lfjr.net]
Sent: Thursday, October 21, 2004 8:45 AM
To: Jakarta Commons Developers List
Subject: Re: [configuration] ConfigurationFactory & namespaces
I don't use ConfigurationFactory but it's definitely useful as a central
place to configure an application. I think we could even push the
concept a bit further, after all, the configuration descriptor read by
ConfigurationFactory *is* a configuration, it's even a file based
configuration that should be automatically reloaded when the file is
changed. So, what about the following ideas:
- remove the namespace handling
- make ConfigurationFactory implement FileConfiguration (it already has
the set/getBasePath() and setGetFileName() methods, load() is easy to
implement with the current code and there is no need to implement save()
since it's read only)
- add a <composite> element to load another composite configuration
descriptor
- not sure about this one, but ConfigurationFactory and
CompositeConfiguration could maybe be merged...
Emmanuel Bourg
Eric Pugh wrote:
> Simplicity I think is always a good idea.. I don't use it.. I will
say, I
> am not too keen on the ConfiguraitonFactory anyway... I think I made a
hash
> of things when first writing it...
>
> Eric
>
>
>>-----Original Message-----
>>From: Emmanuel Bourg [mailto:smanux@lfjr.net]
>>Sent: Wednesday, October 20, 2004 3:52 PM
>>To: Jakarta Commons Developers List
>>Subject: [configuration] ConfigurationFactory & namespaces
>>
>>
>>While reviewing ConfigurationFactory I stumbled on the namespace logic,
>>may I ask who is actually using it ? It looks like an unnecessary
>>complexity to me, imho it's easier to have several configuration
>>descriptors rather than a single namespaced descriptor.
>>
>>What do you think ?
>>
>>Emmanuel Bourg
Re: [configuration] ConfigurationFactory & namespaces
Posted by Emmanuel Bourg <sm...@lfjr.net>.
I don't use ConfigurationFactory but it's definitely useful as a central
place to configure an application. I think we could even push the
concept a bit further, after all, the configuration descriptor read by
ConfigurationFactory *is* a configuration, it's even a file based
configuration that should be automatically reloaded when the file is
changed. So, what about the following ideas:
- remove the namespace handling
- make ConfigurationFactory implement FileConfiguration (it already has
the set/getBasePath() and setGetFileName() methods, load() is easy to
implement with the current code and there is no need to implement save()
since it's read only)
- add a <composite> element to load another composite configuration
descriptor
- not sure about this one, but ConfigurationFactory and
CompositeConfiguration could maybe be merged...
Emmanuel Bourg
Eric Pugh wrote:
> Simplicity I think is always a good idea.. I don't use it.. I will say, I
> am not too keen on the ConfiguraitonFactory anyway... I think I made a hash
> of things when first writing it...
>
> Eric
>
>
>>-----Original Message-----
>>From: Emmanuel Bourg [mailto:smanux@lfjr.net]
>>Sent: Wednesday, October 20, 2004 3:52 PM
>>To: Jakarta Commons Developers List
>>Subject: [configuration] ConfigurationFactory & namespaces
>>
>>
>>While reviewing ConfigurationFactory I stumbled on the namespace logic,
>>may I ask who is actually using it ? It looks like an unnecessary
>>complexity to me, imho it's easier to have several configuration
>>descriptors rather than a single namespaced descriptor.
>>
>>What do you think ?
>>
>>Emmanuel Bourg
RE: [configuration] ConfigurationFactory & namespaces
Posted by Eric Pugh <ep...@upstate.com>.
Simplicity I think is always a good idea.. I don't use it.. I will say, I
am not too keen on the ConfiguraitonFactory anyway... I think I made a hash
of things when first writing it...
Eric
> -----Original Message-----
> From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> Sent: Wednesday, October 20, 2004 3:52 PM
> To: Jakarta Commons Developers List
> Subject: [configuration] ConfigurationFactory & namespaces
>
>
> While reviewing ConfigurationFactory I stumbled on the namespace logic,
> may I ask who is actually using it ? It looks like an unnecessary
> complexity to me, imho it's easier to have several configuration
> descriptors rather than a single namespaced descriptor.
>
> What do you think ?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org