July 2016 - cdi-dev - Jboss List Archives

Weld experimental APIs and related spec issues

by Martin Kouba

Hi all, I'm just looking at Weld 3 experimental APIs and I believe some of the related issues might deserve more attention of the CDI EG: Interceptor bindings available via InvocationContext ==================================================== - https://issues.jboss.org/browse/CDI-468 - http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/#_interceptor_bin... - does anybody know whether an interceptors spec update will be part of EE 8? Support repeating annotations ============================= - https://issues.jboss.org/browse/CDI-460 - https://issues.jboss.org/browse/CDI-471 - http://weld.cdi-spec.org/news/2014/10/02/weld-300Alpha1/#_repeatable_qual... - https://issues.apache.org/jira/browse/OWB-1004 InterceptorBuilder ================== - allows to create an interceptor bean without the need to create a class: http://weld.cdi-spec.org/news/2016/02/04/weld-300Alpha15/ - https://issues.jboss.org/browse/WELD-2008 Thanks, Martin

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation

by Lucas Ventura Carro (JIRA)

[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ] Lucas Ventura Carro commented on CDI-414: ----------------------------------------- Is the only one I have in mind, but I usually avoid {{Instance}} because I've found it really hard to understand how works internally and really dependent on how al the involved beans are. > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation

by Pavel Pscheidl (JIRA)

[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ] Pavel Pscheidl commented on CDI-414: ------------------------------------ [~lucasvc] Do you mean the case where destructor is not called and should be ? Or are there any other cases for potential memory leaks on your mind ? > Support for "self" injection or intercepted self invocation > ----------------------------------------------------------- > > Key: CDI-414 > URL: https://issues.jboss.org/browse/CDI-414 > Project: CDI Specification Issues > Issue Type: Bug > Components: Resolution > Reporter: arjan tijms > Fix For: 2.0 (discussion) > > > Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied. > This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g. > {code} > @Stateless > public class Foo { > @EJB > private Foo self; > // ... > } > {code} > Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb > Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs: > {noformat} > WELD-001443 Pseudo scoped bean has circular dependencies. > {noformat} > See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb > Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well. > With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-560: ------------------------------------- Fix Version/s: (was: 2.0 (proposed)) > A bean archive does not have to contain a beans.xml file > -------------------------------------------------------- > > Key: CDI-560 > URL: https://issues.jboss.org/browse/CDI-560 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Environment: Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > An archive which: > contains a beans.xml file with the bean-discovery-mode of none, or, > contains an extension and no beans.xml file > is not a bean archive. > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0-EDR2 > > > Section 5.1 Modularity: The library is a bean archive if it contains > a beans.xml file, as defined in Bean archives. > It contradicts with the section 12.1 > {quote} > An archive which: > * contains a beans.xml file with the bean-discovery-mode of none, or, > * contains an extension and no beans.xml file > is not a bean archive. > {quote} > Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none". > I think it is better to be "The library may be a bean archive, as defined in Bean archives." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-611) Enhance 10.3.3. Multiple event qualifiers section

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-611?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-611: ------------------------------------- Fix Version/s: 2.0-EDR2 > Enhance 10.3.3. Multiple event qualifiers section > ------------------------------------------------- > > Key: CDI-611 > URL: https://issues.jboss.org/browse/CDI-611 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > Fix For: 2.0-EDR2 > > > While the current spec is in fact correct, it is quite hard to decipher what it is actually trying to convey. > Elsewhere in the spec, we talk about subsets of qualifiers while here we don't. There is a code sample and a sentence saying *"Then this observer method will only be notified if all the observed event qualifiers are specified when the event is fired:"* > This can be interpreted as: > * _"I must fire an event with exactly the same qualifiers as this observer has in order to notify it"_ (*wrong assumption* - it can have more qualifiers) > * _"I must fire an event which will contain at least the same qualifiers as this observer has in order to notify it"_ (*correct* - yet not so obvious) > I will try to come up with some improvement to make this clear. As it is, it always takes me several reading to soak it in. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand closed CDI-548. ------------------------------------ Resolution: Out of Date > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Fix For: 2.0 (proposed) > > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-548: ------------------------------------- Fix Version/s: 2.0 (proposed) > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > Fix For: 2.0 (proposed) > > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-600) Specialization code sample is misleading

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-600?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-600: ------------------------------------- Fix Version/s: 2.0-EDR2 > Specialization code sample is misleading > ---------------------------------------- > > Key: CDI-600 > URL: https://issues.jboss.org/browse/CDI-600 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 2.0-EDR1 > Reporter: Matej Novotny > Fix For: 2.0-EDR2 > > > In the spec, there is following code sample explaining how to achieve specialization: > {code} > @Alternative @Specializes > public class MockAsynchronousService extends AsynchronousService { > ... > } > {code} > This is IMHO misleading as the {{@Alternative}} annotation is not needed for specialization to work and hence should be removed from this sample. In fact one user approached me recently, asking me some questions regarding CDI specialization, and this sample was a source of his confusion. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reopened CDI-548: -------------------------------------- > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand closed CDI-548. ------------------------------------ Resolution: Out of Date async event don't use a specific exception anymore > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2016