You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe this is useful in a limited number of cases, which are nevertheless pretty common. Typical example would be marking an alternative implementation of some bean as a test double -- in such case, you always want it enabled.
The text was updated successfully, but these errors were encountered:
I imagine this could be useful when used on several classes that are to become enabled alternatives for various bean types.
Other than that though, I am not so sure it has much use. You cannot put the same priority on several alternatives that might conflict during typesafe resolution and having several interceptors with the exact same priority sounds like bad practice because you then cannot control ordering (and it might differ in each impl).
To be clear, I am not against this. I can see some use cases for it, just saying that it can also bring more space for user errors,
If we decide to add this, we're going to need detailed TCKs for scenarios where its expected to work plus some of those that shouldn't work (enablement of two impls of Foo both of which inherit same priority etc).
We can mention this tomorrow during the meeting and come to a conclusion. I am pretty neutral on this but I don't see any strong argument against it as it shouldn't break existing behavior.
https://issues.redhat.com/browse/CDI-695
I believe this is useful in a limited number of cases, which are nevertheless pretty common. Typical example would be marking an alternative implementation of some bean as a test double -- in such case, you always want it enabled.
The text was updated successfully, but these errors were encountered: