Manik Surtani wrote:
On 2 Nov 2007, at 15:44, Brian Stansberry wrote:
> Manik Surtani wrote:
>> 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"
> 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
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).
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
> 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. :(
Lead, JBoss Cache
Lead, AS Clustering
JBoss, a division of Red Hat