[jbosscache-dev] Re: Problems with DefaultCacheFactory

[Manik Surtani]

<SNIP />

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

Fair enough, I suspected it would be the case.

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