July 2016 - cdi-dev - Jboss List Archives

[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)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-441) Enhance wording for indirect specialization in 4.3.1

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-441?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-441: ------------------------------------- Fix Version/s: 2.0-EDR2 > Enhance wording for indirect specialization in 4.3.1 > ---------------------------------------------------- > > Key: CDI-441 > URL: https://issues.jboss.org/browse/CDI-441 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > In the 4.3.1. Direct and indirect specialization is following: > {quote} > Formally, a bean X is said to specialize another bean Y if either: > • X directly specializes Y, or > • a bean Z exists, such that X directly specializes Z and Z specializes Y. > {quote} > It is not fully straightforward to deduce that the second point here is not just redundant first case, but rather transitive relationship in indirect specialization. > Therefore I think the wording for indirect specialization should be enhanced. Explanation from Jozef is at http://lists.jboss.org/pipermail/cdi-dev/2014-June/005082.html. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-589) Enhance programmatic lookup

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-589: ----------------------------- Description: The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). The new proposal is to enhance {{Instance}} similarly as Weld API does: https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/in... was: The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). The new proposal is to enhance Instance similarly to Weld API: > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance {{Instance}} similarly as Weld API does: > https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/in... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-589) Enhance programmatic lookup

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-589: ----------------------------- Comment: was deleted (was: https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/in...) > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance {{Instance}} similarly as Weld API does: > https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/in... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-589) Enhance programmatic lookup

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-589: ----------------------------- Description: The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). The new proposal is to enhance Instance similarly to Weld API: was: * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object * ignores client proxies See also https://github.com/cdi-spec/cdi/pull/273. > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515). > The new proposal is to enhance Instance similarly to Weld API: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-589) Enhance programmatic lookup

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-589?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-589: ----------------------------- Summary: Enhance programmatic lookup (was: Programmatic lookup - add Instance.release() method) > Enhance programmatic lookup > --------------------------- > > Key: CDI-589 > URL: https://issues.jboss.org/browse/CDI-589 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > * destroys {{@Dependent}} bean instances obtained from the same {{Instance}} object > * ignores client proxies > See also https://github.com/cdi-spec/cdi/pull/273. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts

by Chris Rankin (JIRA)

[ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy... ] Chris Rankin commented on CDI-601: ---------------------------------- That does sound like the solution that I ended up implementing, yes. Except that I had to observe a {{(a)Destroyed(ApplicationScoped.class)}} event on the basis that it was fired before any beans were destroyed. And fortunately I had only one bean that needed this kind of special handling - I had no way of controlling the order in which {{(a)Destroyed(ApplicationScoped.class)}} events were handled. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-601: ---------------------------------- Oops, you're right! {{@Dependent}} beans may not have conditional observer methods. So the observer method would have to be defined on some kind of "holder" bean - any bean which holds references to the relevant {{@Dependent}} bean instances and delegate the notification - but that's basically the solution you describe, right? > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts

by Chris Rankin (JIRA)

[ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy... ] Chris Rankin commented on CDI-601: ---------------------------------- But doesn't this imply that a new {{@Dependent Worker}} bean would then be _created_ in order to handle this {{ApplicationStopped}} event? This seems like "non-obvious" behaviour when I'm trying to destroy existing beans and shut the application down. > Add container lifecycle event fired before container destroys all contexts > -------------------------------------------------------------------------- > > Key: CDI-601 > URL: https://issues.jboss.org/browse/CDI-601 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-540) Clarify CDI container initialization in Java SE

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-540?page=com.atlassian.jira.plugin.sy... ] Martin Kouba resolved CDI-540. ------------------------------ Resolution: Out of Date > Clarify CDI container initialization in Java SE > ----------------------------------------------- > > Key: CDI-540 > URL: https://issues.jboss.org/browse/CDI-540 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > > {{CDIProvider.isInitialized()}} javadoc should be clarified. I believe the spec should be more specific and define what it means for a CDIProvider to be initialized. E.g. _"a {{CDIProvider}} is initialized if at least one CDI container was started and is still running"_. > {{CDI.shutdown()}} currently must throw an {{IllegalStateException}} if the container is already stopped (actually, the javadoc is missing this piece of information). However, there is no way how to find out whether a CDI container is running or not. {{CDIProvider.isInitialized()}} would be usable if multiple running containers were forbidden (which I hope will not be). Also it wouldn't make sense to ask an instance of {{CDIProvider}} whether a concrete {{CDI}} instance is running... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2016