> > 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. >
I think you might be confused by Hazelcast's capabilities. Hazelcast can easily run in the same process-space (in-memory) as your application, and it's a java .jar file - no 'installation' necessary. Deployed this way (as a simple .jar file included in your app), Hazelcast is effectively the same as a Guava cache: they're both single-JVM/in-memory and both lightweight. To put it another way, Hazelcast and Guava are (effectively) equal choices in this deployment mode. But here is why Hazelcast can be better than Guava, especially as a default cache solution: the instant you decide you need to move beyond simple in-memory/in-process caching, you just have to 'turn on' Hazelcast's clustering. You will instantly have a clustered cache, and you didn't have to change anything in your app other than some config. Guava cannot do this. This is why I personally think Hazelcast is a better default offering for Shiro's community: it is Apache licensed and it satisfies the needs of our entire community, from small, single-JVM applications to the largest distributed clustered SaaS web applications. Additionally, by being able to use the same cache mechanism, regardless of the size of your application, you can become proficient with one cache mechanism and use it in any situation - no need to learn 1 caching product for situation X and another caching product for situationY. Oh, and Hazelcast can serve the Memcache protocol so memcache clients work with it too (if you require that) :) > Ehcache, Terracota are such solution are a last resort (admin cost...) > > 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. Shiro is fully compliant with the ASF's requirements regarding LGPL (we don't subclass or implement any LGPL interfaces or classes - we just invoke them, and this is allowed by the ASL). However, if we can avoid LGPL entirely and use an equally powerful / feature-rich Apache-licensed project, it's a simple choice for an Apache project to use the ASL-versioned dependency instead of the LGPL one; it is just 'safer', and less for the dev team to worry about (especially as it regards long-term maintenance). Thanks again for your continued feedback - you help make the community stronger! Best, Les
