6:06 a.m.
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.
Regarding the methods you have, around getCacheNames, getCache,
releaseCache, etc., I wonder whether this should be a part of the
DefaultCacheFactory.
The bit on profiles - the ConfigurationRegistry as you called it -
makes sense to be separate though, since this is where profiles can be
saved/shared.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
10:44 a.m.
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?
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.)
The bit on profiles - the ConfigurationRegistry as you called it -
makes
sense to be separate though, since this is where profiles can be
saved/shared.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
1:28 p.m.
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
3:07 p.m.
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(a)jboss.org
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
9:38 p.m.
This is done as discussed on this thread.
Manik Surtani wrote:
On 2 Nov 2007, at 20:07, Brian Stansberry wrote:
>
> Sorry I got to this so late in the game. :(
Better late than never. :-) Just glad it's getting done properly.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
6260
days inactive
6266
days old
jbosscache-dev@lists.jboss.org
5 comments
2 participants
participants (2)
-
Brian Stansberry -
Manik Surtani