commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [configuration] Alternative ConfigurationFactory
Date Thu, 09 Mar 2006 20:27:43 GMT
The XMLConfigurationFactory class was renamed to
DefaultConfigurationBuilder and a (rather simple) ConfigurationBuilder
interface was extracted. I think, this is a starting point. Do you think
the interface needs more methods? I would like to keep it as lean and
generic as possible.

Oliver

Oliver Heger wrote:

> Jörg Schaible wrote:
>
>> Hi Oliver,
>>
>> Oliver Heger wrote on Thursday, March 02, 2006 4:14 PM:
>>
>>> Jörg Schaible wrote:
>>
>>
>> [snip]
>>
>>>> Did you think about an interface for this? Does it make
>>>
>>> sense to have different implementations of such
>>> builders/factories? Initialize from JNDI or DB  (... or
>>> implement inclusion of other configurations as part of the
>>> Configuration core interface)?
>>> I have no concrete use case for multiple implementations of such an
>>> interface ATM, but this does not mean that it won't make sense. It is
>>> certainly possible that somebody might need to create a configuration
>>> from other sources or use a completly different form of the definition
>>> file. So I am +1 for an interface.
>>>
>>> I am not sure what you mean by "implement inclusion of other
>>> configurations as part of the Configuration core interface". Should
>>> every Configuration implementation support the inclusion of
>>> other sources?
>>
>>
>> Well, if we go down the road of multiple implementations for a
>> ConfigurationBuilder (XML, Properties, DB, JNDI, ...) I have slightly
>> a deja vu :)
>
> Yes, and we could probably continue this game on arbitrary meta levels
> introducing configurations for configurations for configurations ... ;-)
>
>>
>> So what about enhancing Configuration for an inclusion mechanism?
>> Several impls already have this (XML, Properties), but not in a
>> generic way and not with the possibility to include parts of the
>> configuration from other sources. I am just thinking out loud here, I
>> am not aware of all the possible implications of this idea (and if it
>> is really necessary).
>>
>> - Jörg
>>
> XMLConfiguration does not support this feature, so it's actually only
> PropertiesConfiguration. I think if inclusion became a mandatory
> feature, it would complicate configuration implementations
> significantly. And exactly for the purpose of combining configuration
> sources ConfigurationFactory was created.
>
> Oliver
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message