[
https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587499#action_12587499
]
Oliver Heger commented on CONFIGURATION-248:
--------------------------------------------
A first step in this direction has been done: There is a new base class
"AbstractFlatConfiguration" that implements many of the features required by a
hierarchical configuration on top of a non hierarchical (i.e. flat)
configuration. So configuration classes derived from this class can still use
their own specific (and flat) way of storing and managing their data, but from
an external point of view behave like hierarchical configurations.
We have yet to define the new, hierarchical Configuration interface.
> Safeguard config source abstraction by using HierarchicalConfiguration as
> supertype for all configs
> ---------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-248
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-248
> Project: Commons Configuration
> Issue Type: Wish
> Affects Versions: 1.3
> Environment: -
> Reporter: Dennis Kuehn
> Fix For: 2.0
>
>
> I hope I get this right:
> When I have a CompositeConfiguration, the nice thing about it is that I don't
> have to care in which file or file type a config entry has been defined. Now
> when part of my CompositeConfiguration has a hierarchical structure and I
> need the API provided by HierarchicalConfiguration, I lose the aforementioned
> abstraction: I need to cast a specific part of my CompositeConfiguration to
> HierarchicalConfiguration. This is a major design problem!
> It would be better to leverage the Composite Pattern here: derive all
> configuration classes from HierarchicalConfiguration. Put differently, move
> the HierarchicalConfiguration API to Configuration. Even if a config is not
> hierarchically structured, methods for hierarchical access will be present,
> but that's a minor drawback which is intrinsic to the Composite Pattern. This
> also happens when you are modelling a tree structure and you have a common
> supertype "Node" which has a method "getSubNodes()" which will also be
> present in leaf node instances (in this case, "getSubNodes()" would return
> null etc.).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
