ehcache / ehcache-shiro Goto Github PK

The current implementation is open to races.

Assuming we can make that return collection unmodifiable - which seems to be the case in current implementation of the ehcache 2.x module, it would be better to have a delegation model to the cache, thus making sure we do not have to materialise the whole value collection on heap.

Calling EhcacheShiroManager.init()followed byEhcacheShiroManager.setCacheManager will make the 'EhcacheShiroManager' close the passed CacheManager on destroy() although its lifecycle is supposed to be managed outside.

Hi there,

if a cache is not configured in ehcache.xml, you'll get a NPE.

The problamatic part is configurationbuilder which can be null. You still call the build() method without checking.

Suggestion:

      if (null == configurationBuilder) {
        throw new IllegalStateException("No configuration for the cache with the name [" + name + "] was found. "
            + "Please add it to your ehcache.xml file.");
      }

Current code hardcodes the configuration to a specific XML file.

There should be an option - in a Shiro compatible way ideally - to specify a custom config file.

Also we should not read the config file each time a cache needs to be created as is currently the case.

The current implementation is open to races.

The current implementation is opened to races.

From a quick look, org.apache.shiro:shiro-core:1.1.0 provides already the caching API.
If we could announce that our module works with versions 1.1.0 and above (or even older ... just checked Maven Central but maybe other version exist elsewhere) it would be awesome.

Calling EhcacheShiroManager.init() followed by EhcacheShiroManager.setCacheManager will make the EhCache's CacheManager created by 'EhcacheShiroManager' unreachable. Consider the following test case:

EhcacheShiroManager ehcacheShiroManager = new EhcacheShiroManager();
ehcacheShiroManager.init();
CacheManager firstCacheManager = ehcacheShiroManager.getCacheManager();
Assert.assertNotNull(firstCacheManager);

ehcacheShiroManager.setCacheManager(cacheManager);
CacheManager secondCacheManager = ehcacheShiroManager.getCacheManager();
Assert.assertNotSame(firstCacheManager, secondCacheManager);
Assert.assertNotEquals(firstCacheManager, secondCacheManager);

ehcacheShiroManager.destroy();

Assert.assertEquals(Status.UNINITIALIZED, firstCacheManager.getStatus());
Assert.assertEquals(Status.UNINITIALIZED, secondCacheManager.getStatus());

Assuming we can make that return collection unmodifiable - which seems to be the case in current implementation of the ehcache 2.x module, it would be better to have a delegation model to the cache, thus making sure we do not have to materialise the whole key set on heap.

• Prepare pom for release
• Create tag
• Verify release on Sonatype
• Release
• Update README with version information

Looking at what has been picked right now, I would change to the following:

• groupId: org.ehcache.integrations.shiro
• artifactId: shiro-ehcache3

And we also need to decide on a version. Something close to Shiro? To Ehcache 3? or simply independent?

Comments / counter proposals welcome!

Hi, I just tried use the library for my project.
but I found there is a issue in method getResource in class EhcacheShiroManager

the line 164. I found the code always strip the prefix. but when we put the path into. the code use a url for it.

then it always throws a MalformedURLException, and Caused by: java.net.MalformedURLException: no protocol:

I suppose this is a bug for this code.

thanks

Mike