Ralph Goers schrieb:
The problem is that in applications using commons config they would like
to specify an interface in lots of places. HierarchicalConfiguration
would be perfect for that. It should just extend the Configuration
interface.
It was discussed that in configuration2 all configurations are
hierarchical. In this case there would be the single Configuration
interface, but it would offer the enhanced functionality which is now
provided by HierarchicalConfiguration.
I'm also a little confused over CombinedConfiguration and
ExpressionEngine since two versions of these classes are present. I am
assuming that combined/CombinedConfiguration and expr/ExpressionEngine
are the correct classes and the others should be removed?
Yes, that's correct. Currently DefaultExpressionBuilder still uses the
old classes because not all Configuration implementations supported by
this class have been converted to the new model.
Oliver
Ralph
Oliver Heger wrote:
Ralph Goers schrieb:
I've noticed that HierarchicalConfiguration isn't part of the
inheritance for the various hierarchical implementations. This seems
rather odd. What base class are applications migrating to
configuration2 supposed to convert all their references to? In fact,
I'm wondering if HierarchicalConfiguration shouldn't just be
converted to an interface that AbstractHierarchicalConfiguration
implements.
Well, first of all, this branch is really experimental and far from
being stable.
For configuration2 the intension was to make all configurations
hierarchical. Because of this there does not seem to be much point in
calling a configuration class "HierarchicalConfiguration".
The HierarchicalConfiguration class exists there for legacy reasons
only because some classes still rely on it. When refactoring is
complete it can be removed. With AbstractHierarchicalConfiguration
there is a new implementation based on the new NodeHandler approach.
(Later this class will probably merge with AbstractConfiguration.) The
new counterpart to HierarchicalConfiguration is called
InMemoryConfiguration.
But, as you certainly see, there is still a lot of work to do, and
also some fundamental decisions are pending. For instance, what should
be the exact content of the Configuration interface? I am still on the
opinion that it would be a good idea to have a low-level
ConfigurationSource interface covering only the basics of property
access and a high-level Configuration interface providing a rich API
with many convenience methods.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
