Hi, just for info, do we want to address it or do we want to rely on jsr107?
another i did something close to it because jsr107 is not ready from a cdi point of view (well in quick and dirty mode but it doesn't look too far from it https://github.com/rmannibucau/tatami/tree/master/src/main/java/fr/ippon/tatami/caching ) *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* ---------- Forwarded message ---------- From: Harald Wellmann (JIRA) <[email protected]> Date: 2012/10/17 Subject: [jira] [Created] (DELTASPIKE-282) Extension for caching arbitrary method calls To: [email protected] Harald Wellmann created DELTASPIKE-282: ------------------------------------------ Summary: Extension for caching arbitrary method calls Key: DELTASPIKE-282 URL: https://issues.apache.org/jira/browse/DELTASPIKE-282 Project: DeltaSpike Issue Type: New Feature Reporter: Harald Wellmann Create a CDI equivalent of Spring's cache abstraction, see http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/htmlsingle/spring-framework-reference.html#cache . Basic idea: A @Cacheable interceptor stores the result of method invocations in a cache. Subsequent invocations of the same method with the same parameters take the result from the cache instead of invoking the target method. @Cacheable public ExpensiveResult calculate(String arg) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
