the @Alternative should be the solution to this.
However, note that any alternative which you declare with just this annotations is by default *disabled*.
You can enable it locally (for this bean archive) via beans.xml or globally via @Priority annotation added onto the class - go with @Priority, beans.xml won't help since your WAR is a different bean archive from the JAR.
If this would work then I would recommend it over @Specializes. In fact, @Specializes has a very narrow range of use cases where you truly need it.
The difference between the two is that with alternatives, the original bean is still recognized but never instantiated, e.g. any producer on the original bean would still work.
Whereas @Specializes completely disables the original bean.
Also, if you have a set of modules that you build with and that possibly override each other in impls, then @Alternative allows you to easily specify the winner simply by using appropriate number inside the @Priority annotation.
You can have several priorities and there will always be just one "winner" as a candidate for injection.
Thanks for the detailed explanation. Our use case is that, as `EnhancedGreetingServiceImpl` extends `GreetingServiceImpl` it should always win everywhere. So I think `@Specializes` is what we can use. However, I am still checking CDI docs and haven't started any concrete work. I will soon prepare a test case example.
But yes, if more than one module provides their own versions of extended `GreetingServiceImpl` with `@Specializes` than it could be problematic (there are no such cases yet in our apps). So maybe we'll need `@Alternative` with `@Priority` as you explained. Thanks again, I will give it a try and share here.
Regards
--
Amit Mendapara
