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" package.
That said, #1 and #2 are not good arguments, and #3 is mediocre. Do you
think this stuff belongs in the "factories" package?
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.)
The bit on profiles - the ConfigurationRegistry as you called it -
sense to be separate though, since this is where profiles can be
Lead, JBoss Cache
jbosscache-dev mailing list
Lead, AS Clustering
JBoss, a division of Red Hat