-
Clarification
-
Resolution: Obsolete
-
Major
-
None
-
1.2.Final
-
None
-
None
testDuplicateBindingsToFireEventFails() tests for 2 Lifted literals with different values. But this is perfectly fine as value is NOT annotated as @Nonbinding. Thus the 2 literals are NOT equals according to CDI rules. They are essentially 2 different annotations...
Plz remove this test. It also makes no sense to add all those very performance costly tests at runtime. The worst case which can happen is that the 2 annotations make no sense. But they don't break anything. Wheras checking all the nasty conditions each and every time is really mad from a performance aspect.
[CDI-514] FireEventTest#testDuplicateBindingsToFireEventFails() is wrong
If an invariant of a method is well-defined then the method should validate it.
As for why it is defined this way then I think it enforces consistency between what you can achieve using annotation on classes and what you can achieve programatically. Let's revisit this constraint for CDI 2.0
Mark Struberg (Inactive)
added a comment - correctness? of what? This is currently preventing a perfectly valid use case. IF then it would need to be check for Qualifier equality (taking binding params into account).
But even if not - what happens if a user queries with n times the same qualifier? Nothing, nada, njente. There is just no impact! You will always get back the same Bean.
So it DOES break valid use cases and it DOES NOT prevent some broken cases -> totally useless, and we should fix this.
Mark Struberg (Inactive)
added a comment - correctness? of what? This is currently preventing a perfectly valid use case. IF then it would need to be check for Qualifier equality (taking binding params into account).
But even if not - what happens if a user queries with n times the same qualifier? Nothing, nada, njente. There is just no impact! You will always get back the same Bean.
So it DOES break valid use cases and it DOES NOT prevent some broken cases -> totally useless, and we should fix this. Right, for CDI 2.0 this will need to be revisited. As for the performance impact I don't really buy this. How much time does it take to do a instanceof or class identity check? Especially given that method is usually called with 0, 1 or 2 qualifiers? We should prefer correctness over dubious performance optimizations.
Mark Struberg (Inactive)
added a comment - well thats not true with Java8 anymore...
Also testing this at runtime just doesn't help and just makes the container slower...
Mark Struberg (Inactive)
added a comment - well thats not true with Java8 anymore...
Also testing this at runtime just doesn't help and just makes the container slower... Right, the spec is very clear about this and the TCK follows that.
As for the spec being "broken" it seems that the spec just enforces that the SPI usage is consistent with what the language allows regarding annotations (at most one annotation of a type on a given location).
Mark Struberg (Inactive)
added a comment - it seems the TCK tests what the spec wording says. But the very paragraph in the spec is broken. Will create a spec issue for it.
Mark Struberg (Inactive)
added a comment - it seems the TCK tests what the spec wording says. But the very paragraph in the spec is broken. Will create a spec issue for it. This should be TCK issue right? Yes the instances are not equal but the types are so it seems to me fine. It reflects given assertion IMO.
Tomas Remes
added a comment - - edited This should be TCK issue right? Yes the instances are not equal but the types are so it seems to me fine. It reflects given assertion IMO. Mark Struberg (Inactive)
added a comment - and in org.jboss.cdi.tck.tests.extensions.bean.bytype.BeanByTypeTest
Mark Struberg (Inactive)
added a comment - and in org.jboss.cdi.tck.tests.extensions.bean.bytype.BeanByTypeTest Mark Struberg (Inactive)
added a comment - the very same applies to org.jboss.cdi.tck.tests.event.select.SelectEventTest#testEventSelectWithSubtypeThrowsExceptionForDuplicateBindingType
Mark Struberg (Inactive)
added a comment - the very same applies to org.jboss.cdi.tck.tests.event.select.SelectEventTest#testEventSelectWithSubtypeThrowsExceptionForDuplicateBindingType 
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