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(a)jboss.org