Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow stereotypes to include @Priority #495

Closed
Ladicek opened this issue May 20, 2021 · 3 comments · Fixed by #524
Closed

allow stereotypes to include @Priority #495

Ladicek opened this issue May 20, 2021 · 3 comments · Fixed by #524
Assignees
Labels
spec-feature An issue requesting an addition specification

Comments

@Ladicek
Copy link
Contributor

Ladicek commented May 20, 2021

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.

@manovotn
Copy link
Contributor

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,

@starksm64
Copy link
Contributor

The following todo in core/definition.asciidoc is waiting on the resolution of this issue:

// TODO how about we finally allowed declaring @Priority on stereotypes?

@manovotn
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec-feature An issue requesting an addition specification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants