• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

This change allows the BlockingCache/BlockingCacheManager and their subclasses to specify the CacheManager to use when creating their backing caches.

In the current version, users of BlockingCache or SelfPopulatingCache are forced to use the CacheManager returned by CacheManager.create(). This works fine in basic usage, but if you need multiple CacheManagers or if you want to specify a configuration file manually, you cannot use the constructs.

This change allows the user to pass a CacheManager in to the BlockingCacheManager class, which is then propagated down to the BlockingCache class, which uses the provided CacheManager instead of the default one to create the cache.

The .zip file attached contains the 6 modified source files, all from net/sf/ehcache/constructs/blocking

Thanks!

Scott Sourceforge Ticket ID: 1173725 - Opened By: sdwr98 - 31 Mar 2005 00:02 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320

Scott,

Sorry about the delay in processing this one. ehcache-constructs is my own little collection of caching applications that I don’t update all that often, compared with the ehcache core.

I have applied your patch and written some unit tests to test it.

ehcache-1.2 now allows multiple CacheManagers per VM, without needing to resort to separate classloaders or other tricks. Given that is the case it makes sense to let ehcache-constructs use constructor dependency injection rather than resorting to a Singleton approach to resolve the dependency.

Thanks for your patch! It is in trunk and will be in ehcache-constructs .7 Comment by: gregluck - 6 Mar 2006 03:53 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira