Skip to content

EhCacheCacheManager throws assertion error for ehcache configuration with only default cache configured [SPR-7955] #12610

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Feb 11, 2011 · 5 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Stevo Slavić opened SPR-7955 and commented

Using new spring 3.1 @Cacheable support, and EhCacheCacheManager I get an exception for a valid ehcache configuration - one with only default cache configured:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
    <defaultCache maxElementsInMemory="100" overflowToDisk="false" eternal="true"/>
</ehcache>

Assertion error is thrown from AbstractCacheManager.afterPropertiesSet method at line 46: "Assert.notEmpty(cacheSet);"


Affects: 3.1 M1

Backported to: 3.1.4

1 votes, 4 watchers

@spring-projects-issues
Copy link
Collaborator Author

Costin Leau commented

The defaultCache declaration acts as a template not as an actual cache definition. That is, new caches added programatically will use its settings. Your definition basically declares a template and no caches and thus the error message if valid.

@spring-projects-issues
Copy link
Collaborator Author

Stevo Slavić commented

Costin, doesn't your comment contradict issue resolution? When cache manager is instantiated, and configured using ehcache configuration file with just default cache template, why should it fail if there are no caches defined - as you stated in comment they can be added and also removed programmatically afterwards. So IMO there's no point in validating on initialization that there are caches defined.

@spring-projects-issues
Copy link
Collaborator Author

Costin Leau commented

The fact that caches can be added programmatically doesn't invalidate the validation. When the cache infrastructure is set up, a cache needs to be present (no matter how it was defined) - for sanity reasons. Yes, you could remove the cache afterwards but then you should be able to cope with the consequences.
Hopefully this clarifies the resolution.

@spring-projects-issues
Copy link
Collaborator Author

Marcel Stör commented

I disagree. The <defaultCache> is more than just a template for Ehcache. Two hints:

  • if you use Ehcache as 2nd-level cache for Hibernate you get a warning if you only define <defaultCache> and have cachable entities but the warning also tells you that the default cache will be used
  • additionally to the <defaultCache> add a cache declaration like so <cache name="default" /> and you get an exception telling you that "The Default Cache has already been configured"

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Fixed for both 3.2.1 and 3.1.4, simply removing the assertion.

Juergen

@spring-projects-issues spring-projects-issues added status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.2.1 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants