August 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-623: ---------------------------------- I'm not sure we should specify this. But if we do then we should probably use the same requirements/validation rules for non-configurator methods as well, e.g. for {{AfterBeanDiscoveryImpl.addBean(Bean<?>)}}. Actually, in Weld we already do some simple validation and e.g. throw {{DefinitionException}} if {{getBeanClass()}} returns null. > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-623: -------------------------------- [~antoinesabot-durand] yep, exactly. > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-623: ------------------------------------- Fix Version/s: 2.0 (discussion) > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-623: ------------------------------------------ I guess that [~meetoblivion] is talking of the case were a configurator is requested and the user doesn't do anything with it. That's good point, since the "build" method of these builder is hidden we still have to specify what is the minimum info we have to add to these configurators to be able to build them. So we need: # specify what is the minimum configuration user has to put in a {{BeanConfigurator}} and {{ObserverMethodConfigurator}} to make them viable. Propbaly the same for toher configurator # what shoudl be the behaviour ot eh container in case of a non viable Configurator (abd.add*()) was called and nothing (or non mimimum requirement) was done with the returned configurator. ISE seems to be the best choice here > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-623: ------------------------------------- Labels: F2F2016 (was: ) > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-624) Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-624?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-624: ------------------------------------- Fix Version/s: 2.0 (proposed) > Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle > -------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-624 > URL: https://issues.jboss.org/browse/CDI-624 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > I believe we should not break the application initialization lifecycle. > So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}. > The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-624) Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-624?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-624: ------------------------------------------ Agree with Tomas and John. They should be removed (2nd solution). Dynamic extension is a better feature to focus on IMO. > Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle > -------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-624 > URL: https://issues.jboss.org/browse/CDI-624 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Martin Kouba > Labels: F2F2016 > > I believe we should not break the application initialization lifecycle. > So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}. > The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-624) Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-624?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-624: ------------------------------------- Labels: F2F2016 (was: ) > Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle > -------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-624 > URL: https://issues.jboss.org/browse/CDI-624 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Martin Kouba > Labels: F2F2016 > > I believe we should not break the application initialization lifecycle. > So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}. > The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-625: ------------------------------------- Labels: F2F2016 (was: ) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{(a)Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-625: ------------------------------------- Fix Version/s: 2.0 (discussion) > When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired > ------------------------------------------------------------------------------------------- > > Key: CDI-625 > URL: https://issues.jboss.org/browse/CDI-625 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). > Does it mean that: > * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready? > * {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed? > I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601. > In RI/Weld, the behaivour of {{(a)Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed. > I believe this should be more clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2016