Hi VICTOR PASQUALINO

I have made an automated test based on your sample with ....eeh, let's say a bit more readable class names
Here is a Github link to my branch with the test.

And here is what I think happens (in the brackets are the names of relevant beans in your/my example):

• @Specializes kicks in first and inherits the types and qualifiers (not all annotations! it will not have @ETC) from the bean it specializes and disables it
• As you quoted "When an enabled bean specializes another bean, the other bean is never instantiated or called by the container" - this means the alternative bean (EtcBpmExpressionService/AlternativeFoo) will actually never be called, therefore it will never really disable/overwrite/replace the original bean (EppBpmExpressionService/FooImpl)
• Hence when you try to inject the basic class (BpmExpressionService/AbstractFoo), you surely have the @Specializes bean available for injection, but you also have the most basic implementation(EppBpmExpressionService/FooImpl) as it was not disabled by the alternative
• I think the spec does not actually state what happens first - whether resolution of alternatives of specializations. Therefore this issue might not be a bug.

Solution to make it work the way you (probably) want it to work:

• add @ETC to EtcmpaBpmExpressionService class
• that will turn the class into alternative and disable the original bean (at least in my sample it works - you can find it there commented out)

Does the above help? I'll dig a bit deeper to be certain.