August 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-626: ---------------------------------- [~arjant] Good point. I would guess that you mostly get some {{javax.naming.NamingException}} today. > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Arjan t (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Arjan t commented on CDI-626: ----------------------------- Additionally, what about the bean manager obtained from JNDI? In Mojarra we use that as well (it's on my TODO list to make sure we use the same method everywhere). I haven't tried it yet, but in that case would the bean manager simply not be present in JNDI, or would a non-functional one be returned, or... ? > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-626: ---------------------------------- Hm, I see. But if we do then a {{CDIProvider}} would have to return some "uninitialized" {{CDI}} instance anyway. So I don't see a difference here. Either CDIProvider impl or CDI impl would have to handle this. Actually, the returned CDI instance would have to handle this for all methods inherited from {{javax.enterprise.inject.Instance}}. From impl point of view, CDIProvider modification will be one method, CDI modification many methods. > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-626: ---------------------------------------- I agree getBeanManager() should throw an exception but also means CDIProvider.getCDI() doesn't otherwise we can't call it. Moreover CDIProvider is a plain SPI today and I think it is good to keep it simple so I would put the behavior in the impl and therefore CDI only. Nice thing doing that is the API stay simple and deployment doesn't affect runtime behavior (OSGi/JBoss module or graph classloading, hierarchical classloading, flat classloading). > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-626?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-626: ---------------------------------- I believe that both {{CDIProvider.getCDI()}} and {{CDI.getBeanManager()}} should throw an {{IllegalStateException}}. But then a user would have no easy way to determine whether a CDI container is running or not (except for catching the exception). > How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? > -------------------------------------------------------------------------- > > Key: CDI-626 > URL: https://issues.jboss.org/browse/CDI-626 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > > We did hit the following situation: > A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). > How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? > We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-626) How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?

by Mark Struberg (JIRA)

Mark Struberg created CDI-626: --------------------------------- Summary: How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps? Key: CDI-626 URL: https://issues.jboss.org/browse/CDI-626 Project: CDI Specification Issues Issue Type: Clarification Reporter: Mark Struberg We did hit the following situation: A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager? We should also define the behaviour of CDI.getBeanManager while we are at it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-625: ----------------------------- Description: 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. was: 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. 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. > 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 > > 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)

7 years, 8 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: ---------------------------------- To sum it up, right now if we have an {{@ApplicationScoped}} bean and want to perform some cleanup before it's destroyed: * use {{@PreDestroy}} callback - this can only be used to perfom "local" cleanup as we should NOT call other {{@ApplicationScoped}} beans from within the callback (the ordering of destruction is not defined) * observe {{(a)Destroyed(ApplicationScoped.class)}} which should be fired _"when the application is destroyed"_; but this could be tricky - see also CDI-625 I believe we should either clarify that {{(a)Destroyed(X.class)}} is fired before the context is destroyed (CDI-625) or introduce a new regular event {{ApplicationStopped}} when an application is stopped, before the container destroys all contexts. > 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)

7 years, 8 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

Martin Kouba created CDI-625: -------------------------------- Summary: 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 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. 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)

7 years, 8 months

1
0
0 / 0

Meeting on today?

by John Ament

Hi, Just wondering if today's CDI EG meeting is happening or not? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

7 years, 8 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2016