Commons Configuration
  1. Commons Configuration
  2. CONFIGURATION-84

[configuration] ConfigurationUtils.copy() does not work for XMLConfigurations with repeated keys

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      Copying an XMLConfiguration using the ConfigurationUtils.copy() method does
      not work if there are repeated keys. The end result is an XMLConfiguration
      with a majority of its properties missing because only the first property
      value for a repeated key is copied to the configuration.

      This can be repeated by taking the example database tables XML file on the
      Jakarta Commons Configuration webpage, loading the configuration into an XML
      configuration, creating a new XMLConfiguration using the empty constructor,
      copying the first to the second using the ConfigurationUtils.copy() method,
      and then perform the property queries as described on the webpage. For
      example, calling getProperty() for 'tables.table(2).name' will fail on the new
      configuration after the original configuration is copied.

      This copying is the basis of my entire implementation because I want to be
      able to copy an XMLConfiguration without having to go to the operating system
      and reload a copy from disc.

        Activity

        Hide
        Oliver Heger added a comment -

        You are right, the ConfigurationUtils.copy() method does not work correctly with
        hierarchical configurations. I assume that all properties are copied, but the
        hierarchical structure is lost. That's why getter methods do not return any data
        for keys with indices.

        Unfortunately this issue is not easy to fix. The current copy() implementation
        is quite generic, a copy for hierarchical configurations must be implemented
        differently because the hierarchical tree of properties must be taken into
        account. What makes things even more complicated is the fact that the property
        trees of the source and destination configuration must be correctly merged,
        otherwise the accessor methods would not work as expected. This merge is non
        trivial.

        What I could offer you is a clone() method in HierarchicalConfiguration. Cloning
        is much easier because no merge of the resulting property trees has to be
        performed (the target tree is empty). Would this be useful for you?

        However for XMLConfiguration the clone() method will have the limitation that
        certain information about the original XML document (e.g. comments or processing
        instructions) is lost. This is because an XMLConfiguration instance that was
        loaded from an XML document associates its properties with the corresponding XML
        elements; if they are changed, the document is updated, too. Now if an
        XMLConfiguration object is cloned, the clone must not point to the same document
        to avoid inconsistencies if both objects are changed.

        Show
        Oliver Heger added a comment - You are right, the ConfigurationUtils.copy() method does not work correctly with hierarchical configurations. I assume that all properties are copied, but the hierarchical structure is lost. That's why getter methods do not return any data for keys with indices. Unfortunately this issue is not easy to fix. The current copy() implementation is quite generic, a copy for hierarchical configurations must be implemented differently because the hierarchical tree of properties must be taken into account. What makes things even more complicated is the fact that the property trees of the source and destination configuration must be correctly merged, otherwise the accessor methods would not work as expected. This merge is non trivial. What I could offer you is a clone() method in HierarchicalConfiguration. Cloning is much easier because no merge of the resulting property trees has to be performed (the target tree is empty). Would this be useful for you? However for XMLConfiguration the clone() method will have the limitation that certain information about the original XML document (e.g. comments or processing instructions) is lost. This is because an XMLConfiguration instance that was loaded from an XML document associates its properties with the corresponding XML elements; if they are changed, the document is updated, too. Now if an XMLConfiguration object is cloned, the clone must not point to the same document to avoid inconsistencies if both objects are changed.
        Hide
        Jeffrey Mock added a comment -

        Actually... I had to do exactly what you described. I had to traverse the
        tree and copy the property values from one configuration to another. A clone
        method would be beneficial (I was hoping for that as well when I ran into this
        problem) for others who run into this.

        Is there any other way in the Configuration API to create an XMLConfiguration
        from another without reloading from an external source? I didn't want to have
        to keep going to the disc to get a new copy of my configuration if I didn't
        have to.

        My big thing is the documentation needs to be updated to reflect that the
        ConfigurationUtils is not applicable to HierarchicalConfigurations. If I knew
        this ahead of time, I would have pursued other avenues.

        Show
        Jeffrey Mock added a comment - Actually... I had to do exactly what you described. I had to traverse the tree and copy the property values from one configuration to another. A clone method would be beneficial (I was hoping for that as well when I ran into this problem) for others who run into this. Is there any other way in the Configuration API to create an XMLConfiguration from another without reloading from an external source? I didn't want to have to keep going to the disc to get a new copy of my configuration if I didn't have to. My big thing is the documentation needs to be updated to reflect that the ConfigurationUtils is not applicable to HierarchicalConfigurations. If I knew this ahead of time, I would have pursued other avenues.
        Hide
        Oliver Heger added a comment -

        I added a clone() method to HierarchicalConfiguration (and to XMLConfiguration
        to deal with the stored XML document) and also updated the javadocs for
        ConfigurationUtils.copy().

        Please let me know if this issue can be closed now.

        Show
        Oliver Heger added a comment - I added a clone() method to HierarchicalConfiguration (and to XMLConfiguration to deal with the stored XML document) and also updated the javadocs for ConfigurationUtils.copy(). Please let me know if this issue can be closed now.
        Hide
        Oliver Heger added a comment -

        Got no feedback, so closing this now.

        Show
        Oliver Heger added a comment - Got no feedback, so closing this now.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jeffrey Mock
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development