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] Resolved: (CONFIGURATION-334) Inconsistent parent nodes in HierarchicalConfiguration when using setRootNode()
Date Tue, 12 Aug 2008 09:42:46 GMT

     [ https://issues.apache.org/jira/browse/CONFIGURATION-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oliver Heger resolved CONFIGURATION-334.
----------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.6

A fix was applied, which changes the following:

* If setRootNode() is called, the parent node of the child nodes of the new root are not changed.
So they remain children of the root rather than being added to the HierarchicalConfiguration.Node
that is created for reasons of backwards compatibility.
* The node returned by getRoot() is not created when setRootNode() is called, but it will
be created each time getRoot() is called. Thus it is guaranteed that it is up-to-date and
points to a life snapshot of the node structure in this configuration.

> Inconsistent parent nodes in HierarchicalConfiguration when using setRootNode()
> -------------------------------------------------------------------------------
>
>                 Key: CONFIGURATION-334
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-334
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.5
>            Reporter: Oliver Heger
>            Priority: Minor
>             Fix For: 1.6
>
>
> HierarchicalConfiguration allows setting a root node explicitly using either setRootNode()
or setRoot(). The latter exists for backwards compatibility only and operates on the type
HierarchicalConfiguration.Node rather than ConfigurationNode. To support a corresponding getRoot()
method a new instance of HierarchicalConfiguration.Node is created, and the child nodes of
the root node are added to it. Thus these nodes become child nodes of this new node.
> If now addProperty() is called for adding new properties to the configuration, the nodes
created for the new properties are added to the node passed to the setRootNode() method. So
they have a different parent node than the existing nodes.
> As long as only methods of the Configuration interface are used for querying or manipulating
the configuration, this does not seem to have any strange effects. But when working with the
nodes directly it is certainly confusing.

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