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]
