commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriele Garuglieri (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-224) BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone
Date Mon, 11 Sep 2006 07:41:23 GMT
    [ http://issues.apache.org/jira/browse/CONFIGURATION-224?page=comments#action_12433789
] 
            
Gabriele Garuglieri commented on CONFIGURATION-224:
---------------------------------------------------

Hi Oliver,
i agree with you that directly manipulating a list object returned by getProperty() is rather
unusual, but i don't think making the returned object unmodifiable keeps you safe from the
worst side effect of this problem.

The real case that made me aware of this problem is as follows.
Based on the new events mechanism i implemented a PropertyListener by which you can specify
one or more properties to monitor for changes. One of the options it gives is that user can
specify  he wants to be notified only if the property value really changes. I.e. events like
file reloads for properties that are reloaded with same value are filtered out.
To allow this the listener saves the old property value to match it against the new value,
but in case of a collection value the old value is just a reference to the value in store.
This means that addProperty() or a file reload against a Collection object cause change events
to be issued but  when they arrive both old value and new value refers to the same object
hence, either changed or not, the comparison ALWAYS gives perfect match. So real change events
are lost.

I was not able to find a solution to this other than the returned property value is a different
object than the one in store.

Also think of cases where a casual user that didn't implemented any configuration listener
holds a reference to a Collection object. If another thread changes the object in store, as
a side effect also changes what the user refers too, but he may never become aware of that
unless he always tests the size() of the Collection before he accesses it.

IMO this should go into 1.3 because side effects that cause unexpected changes are always
dangerous.

> BaseConfiguration.getProperty() returns reference to intenal store collection object
instead of a clone
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CONFIGURATION-224
>                 URL: http://issues.apache.org/jira/browse/CONFIGURATION-224
>             Project: Commons Configuration
>          Issue Type: Bug
>         Environment: 1.3RC2
>            Reporter: Gabriele Garuglieri
>            Priority: Minor
>         Attachments: list.patch
>
>
> When the property object is a List or an Array, BaseConfiguration.getProperty() returns
a reference to the object contained in the store.
> This means that changing that object, changes the content of the properties store without
an explicit setProperty() or addProperty(). 
> Also any change to the object in the store will change the object that the code has reference
to, but the user is not aware that the property has changed unless he has added a ConfigurationListener.
> Attached a patch to make the object returned by BaseConfiguration.getProperty() a clone
of store content, to avoid side effects when changing Collection properties.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message