[ https://issues.apache.org/jira/browse/SLING-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler reassigned SLING-2786: --------------------------------------- Assignee: Carsten Ziegeler > ResourceMetadata contains stale unmodifiableMap cache after clone() > ------------------------------------------------------------------- > > Key: SLING-2786 > URL: https://issues.apache.org/jira/browse/SLING-2786 > Project: Sling > Issue Type: Bug > Components: API > Affects Versions: API 2.3.0 > Reporter: Lukas Eder > Assignee: Carsten Ziegeler > Priority: Minor > Fix For: API 2.5.0 > > Attachments: ResourceMetadata.java.clone.patch, > ResourceMetadataTest.java.patch > > > Super types of ResourceMetadata (java.util.HashMap and java.util.AbstractMap) > correctly implement caching for members such as entrySet, keySet, values, > etc. Two things should be considered: > 1. The cache should be marked transient. It is not desireable to serialise / > deserialise the "unmodifiableMap" cache. Only the isReadOnly flag should be > serialised > 2. clone() should be overridden in order to reset the cache on cloned > instances > Consider the following code: > ResourceMetadata map1 = new ResourceMetadata(); > map1.put("key1", "value1"); > map1.lock(); > map1.values(); // Enforce the creation of the cache > ResourceMetadata map2 = (ResourceMetadata) map1.clone(); > Now, map2 contains an unmodifiable wrapper of map1. While this generally > behaves correctly, there are two problems: > a) This is a potential memory leak as clones hold a reference to the original > map. > b) If unlock() is ever added, this might lead to a subtle bug when (after the > above code): > - map1.unlock() is called > - map1 is modified > - map2 will reflect map1's modifications, even if map2 should still be > locked -- This message was sent by Atlassian JIRA (v6.1.5#6160)