Hi [~victorpasqualino]
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|https://github.com/manovotn/core/tree/weld2241/tests-arquillian/src/test/java/org/jboss/weld/tests/specialization/weld2241] 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 _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.
|
