shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Torres Serrano (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SHIRO-481) Provide CacheManager implementation based on Guava caching API
Date Wed, 28 Jan 2015 12:08:34 GMT

    [ https://issues.apache.org/jira/browse/SHIRO-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295084#comment-14295084
] 

Erik Torres Serrano commented on SHIRO-481:
-------------------------------------------

When used with multiple realms, you will need to check that null keys are not passed to the
ShiroCacheToGuavaCacheAdapter, otherwise the authentication will fail due to a NullPointerException
silently ignored by Shiro. Just add a condition to the methods inherited from the class org.apache.shiro.cache.Cache
to avoid null keys to be passed.

> Provide CacheManager implementation based on Guava caching API
> --------------------------------------------------------------
>
>                 Key: SHIRO-481
>                 URL: https://issues.apache.org/jira/browse/SHIRO-481
>             Project: Shiro
>          Issue Type: Wish
>          Components: Caching 
>    Affects Versions: 1.2.2
>            Reporter: Brendan Le Ny
>            Priority: Minor
>              Labels: features, patch, performance
>         Attachments: SHIRO-481.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Guava has become a common library used in many projects.
> Provided default implementation (MemoryConstrainedCacheManager) seems to retain data
in cache for too long for common cases.
> Others implementation (ehcache, terracotta) require the developper to add some dependencies.
> Guava provides a caching API [1]. It's convenient since it's in-memory and thread-safe,
Guava has a mature quality code base and it support few tweaking options:
>     concurrencyLevel
>     initialCapacity
>     maximumSize
>     maximumWeight
>     expireAfterAccess
>     expireAfterWrite
>     refreshAfterWrite
>     weakKeys
>     softValues
>     weakValues
>     recordStats
> I've already programmed the whole thing (patch provided) 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).
> We could just put this CacheManager implementation in shiro-core or in shiro-cache module
or in it's own module (but i think a module for a single class is overkill). 
> It's not perfect but i did some Javadoc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message