[jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1047) CacheJmxWrapper and PojoCacheJmxWrapper should allow explicit config of whether to control cache lifecycle

Tue May 22 18:56:52 EDT 2007

     [ http://jira.jboss.com/jira/browse/JBCACHE-1047?page=all ]

Brian Stansberry closed JBCACHE-1047.
-------------------------------------

    Fix Version/s:     (was: 2.0.0.CR2)
       Resolution: Won't Fix

The JBCACHE-1058 fix removes any use case for setting this attribute, so I've reverted it.

> CacheJmxWrapper and PojoCacheJmxWrapper should allow explicit config of whether to control cache lifecycle
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-1047
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1047
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.CR1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> When the lifecycle methods are invoked on CacheJmxWrapper and PojoCacheJmxWrapper, those classes need to decide whether to pass the lifecycle call on to the underlying cache they are wrapping.  They currently make that decision based on how the underlying cache was created:
> 1) If the underlying cache was injected, they don't manage its lifecycle (assume whoever injected it, e.g. AS microcontainer will do it.)
> 2) If they constructed the cache themselves from a Configuration, then the lifecycle calls are passed through.
> That's fine for most use cases, but while writing some unit tests yesterday it didn't seem clean when I was doing things programatically. E.g. create a cache, inject it into a wrapper, register the wrapper in JMX, call start on the wrapper.  Underlying cache is not started; code has to call start() on the cache as well. So, I've added a ManageCacheLifecycle attribute to the wrapper's where the desired behavior can be explicitly set.  If the attribute is not set, the default behavior is what I described above.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira