Return-Path: Delivered-To: apmail-commons-issues-archive@locus.apache.org Received: (qmail 51942 invoked from network); 11 Aug 2008 19:15:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Aug 2008 19:15:07 -0000 Received: (qmail 43990 invoked by uid 500); 11 Aug 2008 19:15:06 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 43548 invoked by uid 500); 11 Aug 2008 19:15:04 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 43537 invoked by uid 99); 11 Aug 2008 19:15:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Aug 2008 12:15:04 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Aug 2008 19:14:16 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7159B234C1A5 for ; Mon, 11 Aug 2008 12:14:44 -0700 (PDT) Message-ID: <1842113493.1218482084463.JavaMail.jira@brutus> Date: Mon, 11 Aug 2008 12:14:44 -0700 (PDT) From: "Oliver Heger (JIRA)" To: issues@commons.apache.org Subject: [jira] Created: (CONFIGURATION-334) Inconsistent parent nodes in HierarchicalConfiguration when using setRootNode() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 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.