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
>

Reply via email to