EHC ❯ Ehcache needs to expose interfaces instead of concrete classes

• Type: New Feature
• Status: Closed
• Priority: 2 Major
• Resolution: Won't Fix
• Component/s: ehcache
• Labels:

• Assignee:
• Reporter: jwudm
• Created: April 23, 2010
• Votes: 0
• Watchers: 2
• Updated:

  July 27, 2012
• Resolved:

  July 27, 2010

Description

It is very difficult to test at the boundries of where my (client) code and ehcache (api) code meet. CacheManager is not an interface so to mock it out client code needs to make a proxy interface to the CacheManager methods used. Same goes for SelfPopulatingCache.

Comments

Jacob Wu 2010-04-23

The worst is CacheConfiguration. You can’t proxy it with cglib because the methods you care about are all final. EasyMockExtensions fail because some of the methods call things internally which cause null pointer exceptions. e.g., “setMaxElementsInMemory”: java.lang.NullPointerException at net.sf.ehcache.config.CacheConfiguration.fireMemoryCapacityChanged(CacheConfiguration.java:1319) at net.sf.ehcache.config.CacheConfiguration.setMaxElementsInMemory(CacheConfiguration.java:397) at …

Fiona OShea 2010-04-27

right now we are prioritizing backward compatibility which would make this difficult.

gluck 2010-07-27

I think this is a style thing rather than a real need. JCache also has a concrete CacheManager. You can use getEhcache which is an interface if you want to use decorators or mock out a cache.