[jbosscache-dev] JBCACHE-1156 - configuration profiles

[Brian Stansberry]

Manik Surtani wrote:
> 
> On 2 Nov 2007, at 15:44, Brian Stansberry wrote:
> 
>> Manik Surtani wrote:
>>> Brian,
>>> I had a look at what you checked in for this; it looks pretty good, 
>>> but why a package called 'registry'?  This tends to make me think of 
>>> other things, like a component registry, perhaps something related to 
>>> DI even.
>>
>> I went back and forth on that a few times; yeah I guess I went in the 
>> registry direction because:
>>
>> 1) I did ConfigurationRegistry first and its API is more like a registry.
>>
>> 2) For CacheRegistry, my thinking long term for an expanded impl of 
>> this interface in the AS that would also be more like a registry. But, 
>> yeah, looking at the interface now, it's not a registry interface.
>>
>> 3) It didn't really seem to fit w/ the stuff in the "factories" package.
>>
>> That said, #1 and #2 are not good arguments, and #3 is mediocre.  Do 
>> you think this stuff belongs in the "factories" package?
> 
> ConfigurationRegistry - perhaps in the o.j.c.config package, given it is 
> a registry of configurations?
> 

+1; makes sense.

> CacheRegistry methods should perhaps be called CacheManager, given that 
> it "manages" caches by giving you a cache by name, optionally creating 
> it if it doesn't exist?  The more I think about it it doesn't quite fit 
> in CacheFactory either since a factory should just "create" caches, not 
> "manage" them.  I guess both CacheRegistry and CacheManager make sense; 
> I'd lean towards CacheManager though, since this is where JSR107 is 
> heading re: an interface that does the same kind of thing.  

CacheManager sounds good to me too.  CacheRegistry was really a mistake, 
since there is nothing like a "register" method. And I'm not sure there 
ever needs to be one, since a caller that wants to register a cache can 
create a config, register it with the ConfigurationRegistry, and then 
call CacheManager.get(name, true).

 > I still
> don't like the registry package though - maybe this should sit in 
> org.jboss.cache, alongside the Cache interface?
> 

Fine by me; CacheFactory and DefaultCacheFactory are in there as well, 
so it's consistent with that usage.

>>
>>> Regarding the methods you have, around getCacheNames, getCache, 
>>> releaseCache, etc., I wonder whether this should be a part of the 
>>> DefaultCacheFactory.
>>
>> Doing it in DefaultCacheFactory might be OK, but I'd like to maintain 
>> an interface and any needed hooks in other classes to allow this to be 
>> implemented otherwise.  This kind of comes back to my comment on the 
>> JIRA about whether this belongs in JBC at all -- it's basically there 
>> so Hibernate standalone can consume it (w/ EJB3 entities in the AS not 
>> changing in any significant way how that's done.)  But for other users 
>> in the AS (session repl) in the future I may want to do a richer 
>> implementation using a more complex AS-only subinterface. (That could 
>> be done in JBC as well if you think it's generally useful, but for 
>> 2.1.0 I just wanted to focus on meeting the Hibernate need.)
> 
> I think this stuff does make sense in the core cache, since even 
> standalone use would benefit from being able to retrieve an existing, 
> running cache from a manager, not just new caches.
> 

OK, good, glad you feel that way.

Sorry I got to this so late in the game. :(

> Cheers,
> Manik
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> 
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com