JBCACHE-1156 - configuration profiles

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






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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
> manikjboss.org
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev