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
[email protected]
(+33) 02 40 50 29 28
