• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • hhuynh
  • Reporter: tgautier
  • March 25, 2008
  • 0
  • Watchers: 1
  • April 18, 2008
  • April 03, 2008



See attached repro case


Taylor Gautier 2008-03-26


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.