commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
Date Thu, 10 Apr 2008 06:16:04 GMT

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


Mime
View raw message