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 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 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 * All in all, I think this works as expected (e.g. per spec) 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?
|