Allow user applications to introduce server side non-EE interceptors for EE invocations

One of the topics that we discussed in the AS meeting was the use case where users have been demanding for a way to run their application specific interceptors before some of the server side app server specific interceptors and user application specific EE interceptors are run. This will allow for the user applications to have a way to pass in additional information (like security related info) to the server side interceptors (like the security interceptor) so that the information can then be made use for deciding whether or not the call should be allowed to happen or not. We used to allow to do this in previous versions of a AS via AOP but there's no current way to do it in AS7. The EE interceptors come into picture too late.

Some approaches have been discussed around this, during the meeting, with the goal that whatever approach we introduce should be something that we should be able to "support" for a long time without having to ask the users to migrate to a newer way of doing this, in every other major release:

1) Allow the interceptors to use jboss-invocation library to use the interceptor API and implement their interceptors. The advantage of this approach as compared with the other approaches below, is that the semantics of this interceptor interface is something that "we" can decide and wouldn't matter if it conflicts with the semantics of the EE specific interceptors (for ex: EE specific interceptors have a invocationCtx.getTarget() which won't make sense for server side interceptors which are being invoked before the application component has been created)

2) Allow the user applications to just use the EE interceptor API for these intereceptors and we explicitly state that certain APIs like invocationCtx.getTarget() will have different semantics when run as a "system interceptor"

3) Introduce a very small/tiny API (EarlyEEInvocationContext as David calls it ) which exposes limited semantics that the interceptors can rely on.

We are leaning more towards #2 since that wouldn't need any new library or API for these interceptors, but would only require an explicit documentation of what's allowed and what's not in such interceptors.