[jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500624
]
Emmanuel Bourg commented on CONFIGURATION-277:
--
I'm not sure this can be changed, if clearProperty is called in the loop a
ConcurrentModificationException may be thrown. The keys to be removed could be
collected in the loop and then removed outside the loop on the keys iterator.
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500651
]
Michael Rudolf commented on CONFIGURATION-277:
--
I don't have problems with a concrete implementation included in Commons
Configuration but I want to create a new implementation. For the getKeys()
method I decided to use java.util.Arrays.asList(T...).iterator(), as I did not
want to create a new Iterator implementation to wrap around an array of keys.
However, I then realized that the list created by that method does not support
the removal of items but throws an UnsupportedOperationException instead.
Because the iterator calls that very remove() method it will propagate that
runtime exception thus causing the clear() method to malfunction. The point is
that this behavior is perfectly fine, it is documented in the collections
framework. However, the clear method() does not provide for that.
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500846
]
Oliver Heger commented on CONFIGURATION-277:
Well, clearProperty() is already invoked in the loop as a fall back if removing
through the iterator does not work. So for an iterator that does not support
the remove() method there are the following possibilities:
(1) If it operates on a disjunct set of keys, clearProperty() will work and
everything is fine.
(2) If it is affected by clearProperty(), a ConcurrentModificationException
will be thrown. In this case, we have basically transformed the
UnsupportedOperationException into another one, so we have not made things
worse.
In case of (2) the implementor of the derived Configuration class is forced to
write a custom clear() implementation. In case of (1) we have made the
implementor's life a bit easier. So we would have a certain gain.
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500464
]
Oliver Heger commented on CONFIGURATION-277:
Okay, we can change this.
Is there a concrete Configuration class you have trouble with or is the purpose
of this issue just to avoid pitfalls when creating new Configuration
implementations derived from AbstractConfiguration?
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
