Configuration & CacheImpl overlap of concerns

[genman]

There's a lot of logic embedded in CacheImpl.start() and create() as to what specific object instances are created. For example, the JGroups Channel, or the InterceptorChainFactory are directly constructed here and users have no control on this. A bunch of other objects are also created based on class names and whatnot; these are configurable to some extent but why does the CacheImpl need to know how to build these?

What really should be done is allow the Configuration class to play the role as factory class, and take out all factory details from the Cache itself.

I suggest for 2.0 that anything with "new Something()" or Class.newInstance() in Cache be moved to the Configuration object. I would consider moving out the following:

RegionManager
Notifier
StateTransferManager
ReplicationQueue
InterceptorChainFactory
BuddyManager
CacheJmxWrapper
OptimisticTransactionEntry, TransactionEntry

As an example:

public synchronized RegionManager getRegionManager()
 {
 if (regionManager == null)
 {
 regionManager = new RegionManager(this);
 }
 return regionManager;
 }

should be rewritten as:

 public synchronized RegionManager getRegionManager()
 {
 if (regionManager == null)
 {
 regionManager = configuration.createRegionManager();
 }
 return regionManager;
 }

This all somewhat is related to:

http://jira.jboss.com/jira/browse/JBCACHE-1023

[brian.stansberry]

I like the use of Configuration.createX() rather than setX/getX. A concern I have with using the configuration to provide these is it tends to expose the internal objects used by the cache as part of the public API. Using a factory approach gets around that issue, since there's no reason two calls to createX() should return the same instance.

[manik]

I agree with Brian. Furthermore, the configuration is a static representation of values that define how the cache behaves. Contruction is a different story.