Closing all resolved issues in CDI 1.x

As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket.
To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 :

• Guice (and Maven3 new extension mechanism),
• Spring,
• Dagger,

don't implement Interceptor Spec as well.
So I can tell they don't use @Interceptor annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding @Decorator since it's part of CDI spec.
I'll change PR 208 to include this ticket.

+1 for Option 1

I think Option 1 in arnelim comment should be chosen : @Interceptor and @Decorator should become bean defining annotation. We'll propbably extend the annotations list for bean defining annotation with CDI-406, so why not add these 2 as well ?

The option (2) does not deal with interceptors enabled using @Priority (not beans.xml) which still would not be found.

Two options here, I guess:
1. Make @Interceptor and @Decorator a bean-defining annotation
2. Define, that the container must detect the problem that there is an interceptor or decorator enabled through beans.xml that is no bean, because it has no bean-defining annotation.

Should also be done for decorators.

Just a note: although it's not very clear from the spec, interceptors are beans with scope @Dependent. See CDI spec, 6.4.1 Dependent objects:

Many instances of beans with scope @Dependent belong to some other bean or Java EE component class instance and are called dependent objects.

• Instances of decorators and interceptors are dependent objects of the bean instance they decorate.
• ...

So an interceptor from implicit bean archive should explicitly declare @Dependent scope to be processed by the container.

Nevertheless making javax.interceptor.Interceptor a bean defining annotation might be a good idea...