> Generic Question: > 1: Should the interface specification allow limitation of the form of > the names used for the generated clustered objects?
Sorry, but I read this many times and don't really understand what you mean. Can you rephrase? > 2: How should the namespaces be defined for the different types of > objects? You mean for the root creation? > getBarrier, getBlockingQueue: > 1: What should happen if a queue/barrier exists for the given name, > but with a non-matching property (e.g. parties)? Seems like an exception should be thrown, I think we can always detect if the number of parties match. > getDistributedCacheConfig: > 1: Should be called CacheMaker/CacheFactory? That would make clearer > what it does. What about getNewDistributedCacheMaker()? Yeah, it should be renamed if we keep it. > I know that the following methods are marked as needing refactoring, > but a couple of them I figured could do with discussion: > > createLock: > 1: Unclustered monitor object results in? (then what happens if > monitor object subsequently becomes clustered?) IllegalArgumentException > 2: Null monitor object leads to? IllegalArgumentException or NPE > 3: Null lock type leads to? IllegalArgumentException or NPE > lookupOrCreateRoot > 1: Existing root with mismatched type results in? This might be difficult to check for, not sure how to handle it. > 2: Exception in creator results in? I think we should create a dedicated exception for this and throw it, RootCreationException? -- Geert Bevin Terracotta - http://www.terracotta.org _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
