[
https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-248:
---------------------------------------
Fix Version/s: (was: 2.0)
2.x
> 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.x
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
