> >> The reason why I want to make sure we reset RuntimeConfig and clone >> Configuration is if we have 2 cache instances in the same JVM, we >> may need cache-specific instances of more than just the NodeFactory. >> > > OK, that's fine, but > > 1) reset() should limit itself to objects that are clearly meant to > be cache-specific (which is what you did w/ #5 above). > 2) I don't think cloning the configuration is the responsibility of > the CacheFactory. It's the responsibility of the caller. As we > explore use cases for reusing configurations, we may come up with > some classes that help manage configurations for people, e.g. a > ConfigurationFactory similar to JChannelFactory. Those classes could > be responsible for cloning. Fair enough as well, we would have to make sure this is clearly documented. I'd still want to force a reset on the NodeFactory though; a NodeFactory should not exist before a Cache does. Will look into it for BETA1.

> > A problem here is TransactionManager, JChannelFactory and MBeanServer > are kind of neither fish nor fowl. They can reasonably be injected > into the cache and IMHO should be if the environment supports that. > If the environment doesn't support that, we have stuff like > TransactionManagerLookup to substitute for the missing IOC framework. Again, I see what you mean - an IOC framework is sorely missed, maybe at some stage we ought to bring the MC into the JBC core. > > Another thing to consider is whether we want the cache to have the > ability to look up the multiplexer in JMX, or whether that becomes > the task of some other integration layer (e.g. CacheJmxWrapper) that > updates the Configuration and builds the cache. If we remove that > from the cache then: > > a) JChannelFactory is only available from external injection -- i.e. > the cache doesn't add it to its own Configuration. > b) Not sure, but I think we don't need MBeanServer anymore. +1 from me on this; I'm all for the simplicity.

> > That would leave only TransactionManager as the "neither fish nor > fowl" type. > > - Brian