CDI Lite implementations could/should detect CDI Full feature usages

[Ladicek]

We could/should require CDI implementations that implement CDI Lite but do not implement CDI Full to detect (as much as they practically can) usages of CDI features they do not implement and treat them as deployment problem. This would let developers know very early on that they're using unsupported APIs.

The features that should be easy to detect and safe to treat as deployment problems:

• usage of @SessionScoped and @ConversationScoped
• usage of @Interceptors
• declaration of @AroundInvoke interceptors on target classes (as in, on classes that are not interceptors)
• usage of @Decorator, injection of @Delegate
• usage of @Specializes
• injection of Conversation
• injection of InterceptionFactory
• usage of explicit bean archives (bean-discovery-mode="all")
• usage of per-bean-archive enablement (and in general any content of beans.xml besides the bean-discovery-mode attribute)

These features require more delicate treatment:

• declaration of passivating scope (@NormalScope(passivating=true)): if the context is implemented correctly, it is expected to work, there just won't be any passivation
• injection of BeanManager: this is possible in CDI Lite due to compatibility, but only BeanContainer methods must be implemented (the other may throw UnsupportedOperationException)
• usage of Portable Extensions: there's a mechanism for Portable Extensions to coexist with Build Compatible Extensions for gradual migration

These features can't be detected [easily], as far as I can tell:

• relieance on passivation in general
• custom implementations of Bean or Interceptor
• obtaining BeanManager in some other way (not through injection)
• obtaining InterceptionFactory in some other way (not through injection)

I probably missed something, but this should be a list of the most common things people may stumble upon.

(This is a follow-up on #640.)

[m-reza-rahman]

This looks good.