Issues with passivation capable beans and dependencies

Dependencies of interceptors and decorators:

If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean:

• is not passivation capable,
• has a non-transient injected field, bean constructor parameter or initializer method parameter which is not annotated with @TransientReference and that resolves to a dependent scoped bean that is not a passivation capable dependency, or
• has a non-transient injected field, bean constructor parameter or initializer method parameter that resolves to a bean that is not
  a dependent scoped bean and that is not a passivation capable dependency, or
• has an interceptor or decorator with a non-transient injected field that does not resolve to a passivation capable dependency,

then the container automatically detects the problem and treats it as a deployment problem.

It is not enough to validate injected fields of interceptors/decorators only. The specification should require validation of all injection points of an interceptor / decorator also considering @TransientReference

Decorators of built-in beans should be passivation capable

If a managed bean or a stateful session bean which declares a passivating scope type, has a decorator or interceptor which is not
a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem.

Combined with the quote above the specification only requires injection points of a decorator of a built-in bean to be passivation capable dependencies. The specification should also require the decorators themselves to be passivation capable dependencies.