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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
