Very Cool! I agree with Les with being cautious about long term support. However, I noticed we do not have a 'third-party' library page. (Lots of projects do this, but here is an example that sticks out in my mind: http://metrics.codahale.com/manual/third-party/)
I think this would fit for a page like that (at least initially) -Brian On Mon, Jan 6, 2014 at 1:58 PM, Les Hazlewood <[email protected]> wrote: > Hi Brendan! > > Thanks for the notice! I use Guava from time to time myself and enjoy it. > I'm not sure yet if the dev team wants to undertake long term maintenance > of this - I'd personally like to see Hazelcast be our recommended caching > solution (it is Apache 2.0 licensed, which is ideal for Shiro), and it > supports both embedded and clustered modes with full TTL/TTI support. > Until now, Ehcache was sort of the implicit recommended solution since we > have out-of-the-box implementation, but in all honesty I'd personally like > to drop it since it is LGPL (we don't modify or subclass any of their > classes, so we're safe to use it in an Apache project, but there is that > gray area that would be nice to just remove entirely). > > In any event, this is all of course open for discussion, but the best thing > to do to ensure your request isn't lost is to open a Shiro Jira issue and > link the issue to your GitHub project (or wherever else it might be > located) or attach a patch, and then we can discuss it. > > Thanks again! I look forward to your participation! > > Best, > > -- > Les Hazlewood | @lhazlewood > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > > > On Mon, Jan 6, 2014 at 7:27 AM, Brendan Le Ny <[email protected]> wrote: > > > Hi everyone (new subscriber here), > > > > For my current project, I've just made an implementation of CacheManager > > based on Guava. > > > > At first, i was using MemoryConstrainedCacheManager but it seems to > retain > > data in cache for too long for me. > > > > I've seen others implementation (ehcache, terracotta) but these > > dependencies are too large, i don't need all those features. > > > > So i created mine, based on Guava caches [1]. It's convenient to me since > > it's in-memory and thread-safe, Guava has a mature quality code base and > it > > support few tweaking options (sufficient to me): > > > > concurrencyLevel > > initialCapacity > > maximumSize > > maximumWeight > > expireAfterAccess > > expireAfterWrite > > refreshAfterWrite > > weakKeys > > softValues > > weakValues > > recordStats > > > > I've already programmed the whole thing (two little classes) and I was > > wondering if the Shiro team would be interested to integrate this as a > new > > module. It's tiny (no dependency except guava and shiro-cache), it could > be > > just near ehcache support and be convenient for people who don't have big > > caching issues. > > > > It's not perfect but i did some Javadoc, followed your code-style, made a > > minimalistic pom.xml. > > > > [1] https://code.google.com/p/guava-libraries/wiki/CachesExplained > > > > -- > > Brendan Le Ny, Code Lutin > > [email protected] > > (+33) 02 40 50 29 28 > > >
