instrumented java.util.Properties clones as Hashtable

Type: Bug
Status: Closed
Priority: 2 Major
Resolution: Fixed
Component/s:
Labels:

Assignee: hhuynh
Reporter: tgautier
Created: March 25, 2008
Votes: 0
Watchers: 1
Updated:
April 18, 2008
Resolved:
April 03, 2008

Attachments

tgautier (562.0) text/plain Main.java
tgautier (508.0) application/xml tc-config.xml

Description

See attached repro case

Comments

Taylor Gautier 2008-03-26

http://forums.terracotta.org/forums/posts/list/912.page

Tim Eck 2008-03-26

sure looks broken to me too. I think the problem is in HashtableTC.clone() and I think the problem will only occur for *shared* Properties instances. The code in HashtableTC.clone() cannot assume the type of “this” is Hashtable (it can be any subclass of Hashtable)

Abhishek Singh 2008-04-03

Fixed in rev-7917 in 2.6 branch and rev-7918 in trunk.

Changed clone() implementation in HashtableTC to use super.clone() instead of doing a new Hashtable(), which will make the clone type compatible with Properties.

This does not fix a general issue when cloning a logically managed object in a user-defined sub-class of the logically managed Object/Collection results in type incompatibility. (See https://jira.terracotta.org/jira//browse/CDV-703)

Point worth noting is that after super.clone(), it is necessary to iterate over the entries in the hashtable and resolve cleared references (if any) before the clone is returned. Also need to call Util.fixTCObjectReferenceOfClonedObject() to clean up object references of the cloned object. Otherwise the clone (which is not shared) will have ObjectID’s instead of the actual value objects.