[
https://issues.apache.org/jira/browse/CONFIGURATION-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-347.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.6
AbstractFileConfiguration.getKeys() now creates a snapshot of the keys
contained in the configuration when the method is called. Then an iterator of
this snapshot is returned. This avoids ConcurrentModificationExceptions.
Clients should be aware that changes made at the configuration (including those
caused by reload operations) are not reflected by the iterator. The Javadocs of
AbstractFileConfiguration.getKeys() has been updated correspondingly.
> Iterating over the keys of a file-based configuration can cause a
> ConcurrentModificationException
> -------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-347
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-347
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.5
> Reporter: Oliver Heger
> Fix For: 1.6
>
>
> Some implementations of FileConfiguration return an iterator in their
> {{getKeys()}} method that is directly connected to the underlying data store.
> When now a reload is performed (which can happen at any time) the data store
> is modified, and the iterator becomes invalid.
> This behavior is very confusing because ConcurrentModificationExceptions are
> typically related to multi-threading access. But even if the code performing
> the iteration is the only instance that accesses the configuration, the
> exception can be thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
