shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan Le Ny <bl...@codelutin.com>
Subject Re: A Guava-based CacheManager implementation
Date Wed, 08 Jan 2014 09:39:04 GMT
Hi,

Le 06/01/2014 19:58, Les Hazlewood a écrit :
> 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.

In my opinion, Hazelcast (or Ehcache) should not be the first solution 
to come to mind as the recommended solution.

Here is why :
* 80% of Shiro users won't need a cache (because small user base or less 
than 10 simultaneous user on the system, or permissions change to often 
and must be computed each time)
* In the remaining 20%, 80% will need a cache, but a trivial in-memory 
one will be more than sufficient
* On the remaining 20% (of the 20%) who will need a big cache, i would 
recommend an out-of-JVM in-memory cache, memcached in damn simple to 
install, Amazon provide support for GB-sized memcached instances.

(I didn't made any stats, just my experience about the project I had to 
work on.)

Ehcache, Terracota are such solution are a last resort (admin cost...) 
So, i think people who will *really* need to use a big java-ish solution 
like ehcache or terracota (with clusters, replication through JMS, etc.) 
are a minority and as such, should be considered but not the main 
concern. (i don't know the english idiom but in french, i'd say "a 
cannon to kill a fly")

The main concern should be the 80% and providing light implementations 
of CacheManager would be a big plus to Shiro.

I've refactored the whole thing (now extending 
org.apache.shiro.cache.AbstractCacheManager) and now it takes a single 
class with two methods.

Also, Guava is now a common dependency you will find in most of the 
project, just like Apache Commons so providing a Guava support is now a 
common feature. Thus, Guava is already declared and used in Shiro, so it 
wouldn't add any dependency.

So, in my opinion, we could just put this CacheManager implementation in 
shiro-core or in shiro-cache module (because it's absurd to add a module 
for a single class that don't add any dependency).

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

LGPL in not a problem, if you subclass a class, you have to put it in a 
separate module and distribute this module as LGPL but keep Shiro under 
Apache Licence. But I understand you worrying.

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

Will see to create an issue.

> Thanks again! I look forward to your participation!

Thank you too.

-- 
Brendan Le Ny, Code Lutin
bleny@codelutin.com
(+33) 02 40 50 29 28

Mime
View raw message