March 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-514: ----------------------------------- 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. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.sy... ] Tomas Remes edited comment on CDI-514 at 3/4/15 2:56 AM: --------------------------------------------------------- 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. was (Author: tremes): This should be TCK issue right? Yes the instances are not equal but the types are so it seems to fine. It reflects given assertion IMO. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-514: --------------------------------- This should be TCK issue right? Yes the instances are not equal but the types are so it seems to fine. It reflects given assertion IMO. > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.sy... ] SBS JIRA Integration updated CDI-515: ------------------------------------- Forum Reference: https://developer.jboss.org/message/920438#920438 > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance

by Martin Kouba (JIRA)

Martin Kouba created CDI-515: -------------------------------- Summary: Allow to obtain Bean metadata from javax.enterprise.inject.Instance Key: CDI-515 URL: https://issues.jboss.org/browse/CDI-515 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Martin Kouba Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-514: ----------------------------------- and in org.jboss.cdi.tck.tests.extensions.bean.bytype.BeanByTypeTest > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-514?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-514: ----------------------------------- the very same applies to org.jboss.cdi.tck.tests.event.select.SelectEventTest#testEventSelectWithSubtypeThrowsExceptionForDuplicateBindingType > FireEventTest#testDuplicateBindingsToFireEventFails() is wrong > -------------------------------------------------------------- > > Key: CDI-514 > URL: https://issues.jboss.org/browse/CDI-514 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid

by Sven Linstaedt (JIRA)

[ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.sy... ] Sven Linstaedt commented on CDI-513: ------------------------------------ ...and having a PassivationCapable implementing returned by the container, which might be used by custom pseudo scopes. > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-514) FireEventTest#testDuplicateBindingsToFireEventFails() is wrong

by Mark Struberg (JIRA)

Mark Struberg created CDI-514: --------------------------------- Summary: FireEventTest#testDuplicateBindingsToFireEventFails() is wrong Key: CDI-514 URL: https://issues.jboss.org/browse/CDI-514 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Mark Struberg 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-513: ----------------------------------- Let's approach it from a different angle: does the combination non-normalscope AND passivating make sense? Imo it does. This are all the use cases where CDI does not handle the lifecycle (nor applies a proxy) but we would like to get the Serializable check. If anyone comes up with a blocker for this case then I'm perfectly happy to add a check that addScope(Xxx.class, false, true) is an illegal situation. If not then it must get supported. > Clarify whether passivating pseudo-scopes are valid > --------------------------------------------------- > > Key: CDI-513 > URL: https://issues.jboss.org/browse/CDI-513 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466 > I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags. > ----- > AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. > There is nothing in the spec which says that a non-normalscope cannot be passivating. > The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. > Actually the test should come in 2 flavours: > 1.) RomanEmpire being Serializable -> all fine must work > 2.) RomainEmpire not Serializable -> DefinitionException -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2015