[jbosscache-dev] JBCACHE-1156 - configuration profiles

[Manik Surtani]

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?

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

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

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