incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <michael.andre.pea...@me.com>
Subject Re: svn commit: r1293567 - in /incubator/directmemory/trunk: directmemory-cache/src/main/java/org/apache/directmemory/memory/ integrations/ehcache/ integrations/ehcache/src/ integrations/ehcache/src/main/ integrations/ehcache/src/main/java/ integrati
Date Sat, 25 Feb 2012 23:44:56 GMT


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).



On 25 Feb 2012, at 22:07, Simone Tripodi wrote:

> Sorry, I don't understand how it is related to declaring a package in
> the SVN repo that's not org.apache.*
> 
> Thanks anyway, having 3rd parties dependencies that adhere to ASL2.0
> simplifies the release process.
> 
> bets,
> -Simo
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> 
> 
> On Sat, Feb 25, 2012 at 7:58 PM, Michael André Pearce
> <michael.andre.pearce@me.com> wrote:
>> http://ehcache.org/apidocs/
>> 
>> See point 14, code is released under apache license already and approved by asf.
>> 
>> Sent from my iPhone
>> 
>> On 25 Feb 2012, at 15:35, Simone Tripodi <simonetripodi@apache.org> wrote:
>> 
>>> Salut Benoit!
>>> 
>>>> But, EHCache is done in a way that net.sf.ehcache.Cache is looking for
>>>> the class net.sf.ehcache.store.offheap.OffHeapStore
>>>> (http://ehcache.org/xref/net/sf/ehcache/Cache.html#1181).
>>> 
>>> Ouch :( :( Cannot believe they didn't adopt a SPI-alike approach :(
>>> 
>>> Looks like we don't have any chance to change/hack that behavior, so
>>> we can just understand how to having it fixed under the legal PoV.
>>> 
>>> Thanks for the clarification, very appreciated!
>>> 
>>> -Simo
>>> 
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/


Mime
View raw message