InterceptorMethod may need to take a leading receiver-of-sorts parameter

[ljnelson]

Interceptors in CDI and EJB and elsewhere are dependent objects of the things they intercept.

That means, in reflection land, you can have a single interceptor with, say, two interceptor methods on it (one for, say, a lifecycle method type, like @PostConstruct and another for a method-level type, like @AroundInvoke). When the intercepted object is created in this case, so is the interceptor, and its post-construct method may store something in an instance variable that its around-invoke method may read at business method invocation time. The next time creation happens, the old interceptor must be destroyed, and a new interceptor must be created, and so no state must perdure.

This is kind of stupid if reflection is not needed, or, really, in a number of other ways. If an InterceptorMethod were enhanced to be more like:

public interface InterceptorMethod<I> {

  public Object intercept(final I possiblyNotNeededInterceptor, final InvocationContext ic);
  //                              ^ more of a state container, really

}

…then interceptors-using machinery could cache instances of this thing and supply the interceptor instance as needed according to the lifecycle requirements of the machinery. For machinery that doesn't require an actual interceptor, it could just pass null.

The drawback of all this is that the parameter isn't really needed by an InterceptorMethod implementation. You can close over whatever you want to make one of these. But unless you close over a very special kind of Supplier<Interceptor>, you will close over what amounts to a singleton and that is no good in many situations.

Another clunky approach would be to add bindTo(Interceptor i) and unbind() methods, but that adds state to what is effectively a stateless thing right now.