Major Sometimes you see people trying to do
@Inject @ApplicationScoped
private SomeRequestScopedBean sRSB;
It should be clarified that this has no effect. Could even throw a validation exception at deployment.
[CDI-276] Clarify that scope annotations shouldn't be used at injection points
Pete Muir (Inactive)
added a comment - Java EE specifications rarely contain as many error conditions as CDI, nor do they specify what happens in these situations as much as CDI does.
So we could discuss with the EG introducing this warning requirement, but it's diverging a lot from other specs. Also, it would be very hard to test that it actually happens AFAICT.
Pete Muir (Inactive)
added a comment - Java EE specifications rarely contain as many error conditions as CDI, nor do they specify what happens in these situations as much as CDI does.
So we could discuss with the EG introducing this warning requirement, but it's diverging a lot from other specs. Also, it would be very hard to test that it actually happens AFAICT. 
Antoine Sabot-Durand (Inactive)
added a comment - You're right rhn-engineering-jharting but it's far from being my favorite. In fact, I was including it in my first case : Container accept the config and does something (or not) depending on your implementation. IMO we should avoid it as much as possible : it's a way to let holes in the specification.
CDI can be a bit tricky for end user sometimes, so it could be an idea to help them when they're doing something that is irrelevant like trying to inject a bean of a certain scope.
Antoine Sabot-Durand (Inactive)
added a comment - You're right rhn-engineering-jharting but it's far from being my favorite. In fact, I was including it in my first case : Container accept the config and does something (or not) depending on your implementation. IMO we should avoid it as much as possible : it's a way to let holes in the specification.
CDI can be a bit tricky for end user sometimes, so it could be an idea to help them when they're doing something that is irrelevant like trying to inject a bean of a certain scope. There is the "non-portable behavior results" option which allows container to do whatever. This used in many places in the spec.
Antoine Sabot-Durand (Inactive)
added a comment - That brings another point petemuir, In the spec we define a very binary behavior : either the container accept the defined state or the container "treats this as definition error". Shouldn't we also have "the container should raise a definition warning" for case like this one?
Antoine Sabot-Durand (Inactive)
added a comment - That brings another point petemuir , In the spec we define a very binary behavior : either the container accept the defined state or the container "treats this as definition error". Shouldn't we also have "the container should raise a definition warning" for case like this one? Pete Muir (Inactive)
added a comment - But understood that it is a problem, I just think we need to think up something that isn't restrictive but still helpful.
Pete Muir (Inactive)
added a comment - But understood that it is a problem, I just think we need to think up something that isn't restrictive but still helpful. Pete Muir (Inactive)
added a comment - The issue with this one is that someone might want to define an extension that did allow this...
Pete Muir (Inactive)
added a comment - The issue with this one is that someone might want to define an extension that did allow this... 
The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in this GitHub issue.
If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.
For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues