You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Oliver Heger (JIRA)" <ji...@apache.org> on 2008/04/10 08:16:04 UTC

[jira] Commented: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs

    [ 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.