Only thing i would add, is maybe MemoryManagerServiceWithAllocationPolicyEhcacheImpl could change the class name, as obviously originally it was born out the need of slightly different behaviour of MemoryManagerServiceWithAllocationPolicyImpl, but in effect the idea of having it to contain ehcache specifics if need in future ideas i have are:
DirectMemoryManager (under the ehache package) EHCacheMemoryManager thoughts? On 25 Feb 2012, at 23:44, Michael André Pearce wrote: > > > DirectMemoryStore is an implementation of the ehcache store interface for > directmemory and should try contain all the handling of normal store features, > DirectMemoryCache is to support all features needed from directmemory to > support the store, and thus to support extra functions/features or changes of > behaviour for direct memory needed for ehcache integration which we wouldn't > necessarily want to put into the core, agreed atm this does make this a bit > of a pass through layer but i can i can see several items already that would > want specific to ehcache, atm it has two features it is supplying size and > capacity in bytes of the cache. > > On the MemoryManagerServiceWithAllocationPolicyEhcacheImpl this originally > was to change behaviour of MemoryManagerServiceWithAllocationPolicyImpl to > throw boe instead of what was the current behaviour of returning null, (which > actually does cause an npe in the cacheservice implementation which probably > needs to be fixed) , but anyhow, exception behaviour handling allows to wrap > into ehcache cache exception nicely. Benoit migrated this functionality > actually into directmemory core so yes agreed this could be removed now. > (though i would think about leaving it for now maybe, as with like argument > for the directmemory cache, if there is features we want specific to the > ehcache integration, that in furture we wouldnt want in the main core, then > it is can be placed here).
