Comments on new JCache revival JSR wrt Annotations and Interception

In reading the intro and chapter 8 of the JSR 107 revised specification (http://tinyurl.com/jsr107-yeah).

It seems if there are annotations for caching, then we need a way to intercept the method calls and process the annotations.

As manik.surtani brings out in the comments on the google doc JSR 107 specification (http://tinyurl.com/jsr107-yeah).

"""
Does the spec also define how these annotations are used? E.g., would implementations need to:

1. Perform annotation scanning on a classpath
2. Intercept method calls that are appropriately annotated
3. Perform cache storage and retrieval accordingly? —
"""

CDI already does classpath scanning and CDI is a standalone JSR. It would seem that the way to do this would be to use CDI (JSR 299).
Weld (the reference implementation of CDI) has standalone support, i.e., it can be used outside of an Java EE 6 container.
Therefore CDI seems to be a natural choice as the "standard" way to provide this support.
Other frameworks, Spring, Guice, et al can provide compatible implementations of annotation scanning and feature weaving.

Also that Weld is standalone is particular nicety covered by Weld it is not in the 1.0 CDI JSR.
It will not be until the CDI 1.1. There should be some collaboration between this JSR and CDI 1.1.
I would hate two see two forms of classpath scanning and annotation processing.
It would be nice if one JSR built on top of the sweat of another.

(You may already have this planned.)

BTW I have written several AOP frameworks that capture annotations and process them for caching.
(Using Spring AOP, and AspectJ)
I am willing, able and deeply interested in developing some proofs of concepts CDI Extension that work with the new JSR 107 as part of the JSR work.

I recently wrote a CDI Extension that bridges the CDI and Spring worlds.
see http://goo.gl/UwJfU and http://goo.gl/C76sp