Issue Details (XML | Word | Printable)

Key: CONFIGURATION-332
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Oliver Heger
Reporter: Emmanuel Bourg
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Commons Configuration

PropertiesConfiguration.save() doesn't persist properties added through a DataConfiguration

Created: 04/Jul/08 03:54 PM   Updated: 22/Aug/09 07:36 PM
Return to search
Component/s: None
Affects Version/s: 1.5
Fix Version/s: 1.6

Time Tracking:
Not Specified

Resolution Date: 01/Aug/08 07:48 PM


 Description  « Hide
There is a regression in Commons Configuration with PropertiesConfiguration wrapped into a DataConfiguration. The properties added through a DataConfiguration aren't persisted when the configuration is saved, but they can be queried normally. Commons Configuration 1.4 wasn't affected by this issue.

The following test fails on the last assertion :

public void testSaveWithDataConfiguration() throws ConfigurationException
{
    File file = new File("target/testsave.properties");
    if (file.exists()) {
        assertTrue(file.delete());
    }

    PropertiesConfiguration config = new PropertiesConfiguration(file);

    DataConfiguration dataConfig = new DataConfiguration(config);

    dataConfig.setProperty("foo", "bar");
    assertEquals("bar", config.getProperty("foo"));
    config.save();

    // reload the file
    PropertiesConfiguration config2 = new PropertiesConfiguration(file);
    assertFalse("empty configuration", config2.isEmpty());
}


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Oliver Heger added a comment - 01/Aug/08 07:48 PM
There is a problem with DataConfiguration that it does not implement some methods of the Configuration interface by delegating to the wrapped configuration (as a decorator should do), but uses the default implementations inherited from AbstractConfiguration. This can cause unpredictable results if the wrapped configuration overrides one of these methods.

Maybe in 2.0 we should consider reimplementing this class as a true decorator. To be safe it should not extend AbstractConfiguration, but implement all methods required by the Configuration interface manually - delegating to the wrapped configuration.


Emmanuel Bourg added a comment - 01/Aug/08 09:08 PM
Thank you for the fix Oliver.

In 2.0 we could even remove DataConfiguration completely, it could be replaced by the generic getter in AbstractConfiguration.