Hi, While reviewing all the code and reworking it, I came to a realization that I'm going to try to explain correctly.
To be able to use the toolkit without one of our products as an application user, I created the StandaloneClusteringProvider which now turned into TerracottaClient.getToolkit(). This basically creates a Terracotta client and within its classloading context gives access to a toolkit instance. Almost none of the original toolkit methods are really useful for app developers since they can't directly access the classes within the toolkit. I thus created the methods that app dev are interested in: public Barrier getBarrier(String name, final int parties) public TextBucket getTextBucket(String name) public ReadWriteLock getReadWriteLock(String name) public BlockingQueue getBlockingQueue(String name) public BlockingQueue getBlockingQueue(String name, final int capacity) public <K, V> TerracottaMap<K, V> getMap(String name) public TerracottaLock createLock(Object monitor, LockType type) public CacheConfig getDistributedCacheConfig() None of these methods are actually interesting for framework/TIM developers since they can access the types directly. So imho the ClusteringToolkit API is already polluted. I think we should break these out into a dedicated interface that sort of becomes like its own product, something like TerracotaBasics for the lack of better naming idea. There are imho only two methods of the ClusteringToolkit that are interesting for both app and framework developers: public TerracottaCluster getCluster() public String getUniversallyUniqueClientID() I don't see a problem of having these two methods being present in both the ClusteringToolkit and TerracotaBasics. This leaves the following ClusteringToolkit methods: public <T> T lookupOrCreateRoot(String name, Callable<T> creator) public boolean disableEviction(Object o) public boolean enableEviction(Object o) public void waitForAllCurrentTransactionsToComplete() public void registerBeforeShutdownHook(Runnable beforeShutdownHook) public TerracottaLogger getLogger(String name) public TerracottaProperties getProperties() I think they can all be turned into either static helper methods or concrete classes that can be accessed directly by framework/TIM developers. None of them really need the ClusteringToolkitImpl as a class. Tim and I just created it initially with the possibility of allowing different implementations of the toolkit. This is a pipe dream since there are quite a number of usages of ManagerUtil throughout the other toolkit classes. As such, I thus propose we actually remove Clustering, ClusteringToolkit and ClusteringToolkitImpl and create more appropriate classes for the methods above. This also solves the global namespace/scoping refactoring we were planning to do for the ClusteringToolkit methods. I hope I've made myself clear. Any thoughts on this? I actually feel very good about this and want to start working on this refactoring ASAP since the whole Clustering.toolkit() static method class and entry point never felt right to me. Thanks, Geert -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
