change the maxElementsInMemory property inside EhCacheFactoryBean.java to maxEntriesOnHeap, in order to sync with recent ehcache version

removed 1.3.1 fixed version as this is not in that release

Integrated in kernel-trunk #589 (See http://builds.sakaiproject.org:8080/job/kernel-trunk/589/)
https://sakaiproject.atlassian.net/browse/KNL-1008#icft=KNL-1008 change the maxElementsInMemory property inside EhCacheFactoryBean.java to maxEntriesOnHeap, in order to sync with recent ehcache version
Patch from Zhen Q (UM) (Revision 119618)

Result = SUCCESS

Ready for QA
Note that the only real way to test this is to set the value and then check the output in the memory tool or use a profiler to check if it actually picked up on the new settings

patch as applied (KNL-1008.patch.txt)

I think Zhen's patch is good for quick backward compatibility with our custom property syntax (and defaults). But some more detail:

It seems that the big issue here is that Ehcache has new configuration and constructor options [1] as of 2.0 and the Spring factory bean still uses the 1.x constructors and does not recognize the new properties. I think the expectation is that you will not use the factory bean to create the caches as of 2.x (which I missed in the original upgrade work). I assume this is because the conveniences of the factory bean (declarative configuration) are provided by the CacheConfiguration directly (as opposed to passing positional parameters) [2][3], making it effectively obsolete.

Basically, the issue captured in this ticket is that Ehcache expects a property named maxEntriesLocalHeap, but our configuration mechanism expects this concept to be named maxElementsInMemory and does not map it through by default (hence Zhen's patch). This was a significant oversight on my part.

My initial thought toward a resolution that doesn't disrupt too much is to change our beans (impl) and the behavior of BasicMemoryService.instantiateCache (which affects non-bean initiated caches). It currently clones the default cache through reflection and then applies any configuration parsed by CacheInitializer. We should change our bean definitions (with their default configurations) away from EhCacheFactoryBean and to a simple bean with a property for a new, standard CacheConfiguration (bean). Upon init, it should read our idiosyncratic config properties and apply them before creating the cache through the CacheManager. Similarly, instantiateCache should create a CacheConfiguration and apply the values before instantiating the cache (rather than cloning the default).

In the longer run, Spring 3.x has a generic Cache model (very close to JSR-107 and Ehcache), which we should adopt and eliminate the MemoryService entirely. Almost all of the original semantics of the MemoryService have been replaced by Ehcache semantics, but implicitly and incompletely.

Something else that is of interest is that the four most important properties (timeToLiveSeconds, timeToIdleSeconds, maxEntriesLocalHeap, maxEntriesLocalDisk) are now dynamically configurable on the CacheConfiguration of existing caches. It would be pretty easy to expose a runtime setting to adjust these without restarts.

[1] http://ehcache.org/apidocs/net/sf/ehcache/Cache.html - the overloaded constructors are still present, but CacheConfiguration is current.
[2] http://ehcache.org/apidocs/net/sf/ehcache/config/CacheConfiguration.html
[3] http://ehcache.org/apidocs/net/sf/ehcache/config/ConfigurationFactory.html