[jbosscache-dev] Re: Problems with DefaultCacheFactory

> Just to clarify though, I was under the impression the > runtime configuration was generated by the cache, by > attaching various runtime subsystems that are built based on > the configuration XML such as the TM. The reason we exposed > it is so that such systems could be overridden/injected at > runtime by the MC. So it would just need to be a sequence of events > that change: > > 1) create cache > 2) start cache > 3) inject specific subsystems such as the TM > > Does it not work this way with the MC? > No, the MC builds up the entire Configuration structure and then injects it into the bean that instantiates the cache (bean is either a CacheFactory instance or an instance CacheJmxWrapper, which internally uses the CacheFactory). In order to have the runtime objects available when needed, the sequence would need to be: 1) Create config bean x- runtime objects 2) Use config to instantiate cache bean 3) Inject runtime objects into config bean 4) Call create() on cache bean 5) Call start() on cache bean I don't see how the MC could possibly manage that sequence, since it requires weaving together operations on 2 different beans (really 3 beans, since step #2 has a factory involved.) If we used CacheJmxWrapper, and added properties to it for the runtime objects, it could have that sequence hard coded, but that's a nasty hack.

> 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.

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.

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.

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