I think it does make sense to do it now that we have lifecycle tracking anyway. Perhaps an Enum - CacheStatus { UNINITIALISED, INITIALISED, STARTED, STOPPED, DESTROYED }. Do we want transitional states as well - INITIALISING, STARTING, STOPPING, DESTROYING? On 22 May 2007, at 21:40, Brian Stansberry wrote: > Manik, > > Resurrecting an old thread so I can finish up JBCACHE-1058. > > As part of the JBCACHE-1058 work, I've added functionality to > CacheImpl where it tracks what lifecycle stage it's in. Issue then is > whether we want to expose that as part of the Cache API. > > Below it seems like we decided we didn't want to do that, but not sure > if that was just because we didn't want to implement the lifecycle > tracking. Which is now done. > > Let me know what you'd like; it's 30 seconds work either way. > > "Brian Stansberry" wrote: >> Manik Surtani wrote: >>> On 11 Jan 2007, at 15:33, Brian Stansberry wrote: >>> >>>> I should have discussed this before opening JIRA, since the use case >>>> isn't clear, but... >>>> Exposure in JMX makes sense, since we expose the lifecycle >>>> operations, i.e. you stop the cache and your colleague comes and >>>> bugs you, it's nice to be able to see the state it's in when you get >>>> back to work. >>>> I *believe* (pretty sure actually) in AS 5 the MC will uninstall a >>>> bean if it fails in deployment, and this will include deregistering >>>> from JMX. So, the AS 4.x use case of being able to see the status of >>>> a failed deployment in the JMX console probably doesn't apply. >>>> >>>> Are there situations where the cache lifecycle can change internally? >>>> For example, as a result of the channel being shunned and auto- >>>> closing? Right now we don't handle that, but if we did, is it >>>> possible it would trigger a lifecycle transition? >>> >>> True. At the moment though this is not the case. But since >>> this is just an addition of an API, perhaps we add it later when we >>> have the need? >> +1. I reread the JIRA and it's to "consider" the issue. By Beta1, >> since it impacts API. We've now considered it, so pushing it out to >> some future point is fine by me. :-) >> - Brian > > > --Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com > -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani