Infer "shutdown()" as destroy method for convenient EHCache setup using @Bean [SPR-9713]

[spring-projects-issues]

Peter Ledbrook opened SPR-9713 and commented

The most convenient way to set up the Ehcache provider is via the EhCacheManagerFactoryBean class. But factory beans aren't recommended for Java configuration style, so it would be good to have an alternative, such as a builder, that works well with @Bean.

---

Affects: 3.1.1

Issue Links:

• Clarify Bean destroyMethod documentation [SPR-16078] #20627 Clarify Bean destroyMethod documentation
• EhCacheCacheManager does not close underlying CacheManager [SPR-11680] #16303 EhCacheCacheManager does not close underlying CacheManager

Referenced from: commits 4c823a3

1 votes, 3 watchers

[spring-projects-issues]

Chris Beams commented

Thanks, Peter.

One question here will be how to handle destruction, i.e. calling CacheManager's #shutdown method. Option one is to return a proxy from the builder that implements DisposableBean and have #destroy invoke #shutdown. Option two is to add public no-arg methods named #shutdown to the list of recognized methods for Spring's "destroy method inference" (#13393). This list is currently limited to public no-arg methods named "close".

[spring-projects-issues]

Juergen Hoeller commented

I'm reducing this issue to the destroy method inference that Chris suggested, i.e. detecting "shutdown()" as a destroy method by default so that an @Bean method may simply build and return an EHCache CacheManager instance, with no further consideration necessary for destruction purposes.

EHCache itself comes with quite nice programmatic setup options, calling CacheManager.create(...) or new CacheManager(...), potentially with a Configuration argument that comes from the EHCache ConfigurationFactory. I'd like to avoid inventing our own setup API when it's really EHCache that should be evolving its configuration API and isn't too bad at it already.

And well, our EhCacheManagerFactoryBean is a rather convoluted chain of if checks that conditionally calls CacheManager.create(...) or new CacheManager(...) - it does exactly what an @Bean method should do itself. The only added value was automatic destruction which we're dealing with now.

Juergen