I think we can't do much about this now. However, ideally I think we should create a new interface that it's TCMap, but that is created for the sole purpose of allowing a concrete class to provide locality-related data. I don't get your suggestion that says "get the user to do it from outside the cluster info code", care to expand on that.
For now, we might maybe want to exclude these methods from Javadoc? Seems that the yDoc doclet allows this atm and an @exclude tag is in the work: http://java.sun.com/j2se/javadoc/faq/index.html#exclude, http://java.sun.com/j2se/javadoc/proposed-tags.html On 03 Jun 2010, at 14:12, Geert Bevin wrote: >> class ConcurrentDistributedMapImpl >> 1: public __tc_ methods need to be removed from here. They are here >> only so that the cluster info code can kind of work against the map. >> Unfortunately this only works for getKeysForLocalValues, since all the >> others defer to server calls which don't work against the top level >> instance for various internal reasons. I'm thinking that what we >> should do is stop this from having the __tc_ methods (and being >> instrumented with TCMap) completely and instead either get the cluster >> info code to call getConstituentMaps() directly or get the user to do >> it from outside the cluster info code. > > I'm looking into this now, will post more later. -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
