August 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Antoine Sabot-Durand updated CDI-78: ------------------------------------ Fix Version/s: 2.0 (discussion) > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-220: ------------------------------------------ Should be Forbidden IMO. Only a Session Bean can specialized a Session Bean. > behaviour of CDI bean @Specializes session bean is undefined > ------------------------------------------------------------ > > Key: CDI-220 > URL: https://issues.jboss.org/browse/CDI-220 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0, 1.1.EDR > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, F2F2016 > Fix For: 2.0 (discussion) > > > The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g. > @Stateless > public class Horse {..} > @ApplicationScoped @Specializes > public class Trakehner extends Horse {..} > Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error. > Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes session bean is undefined

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-220?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-220: ------------------------------------- Labels: CDI_spec_chge F2F2016 (was: CDI_spec_chge) > behaviour of CDI bean @Specializes session bean is undefined > ------------------------------------------------------------ > > Key: CDI-220 > URL: https://issues.jboss.org/browse/CDI-220 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0, 1.1.EDR > Reporter: Mark Struberg > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, F2F2016 > Fix For: 2.0 (discussion) > > > The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g. > @Stateless > public class Horse {..} > @ApplicationScoped @Specializes > public class Trakehner extends Horse {..} > Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error. > Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-142) Clarify behaviour of specializing beans across bean archive boundaries

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-142?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-142: ------------------------------------- Labels: F2F2016 (was: ) > Clarify behaviour of specializing beans across bean archive boundaries > ---------------------------------------------------------------------- > > Key: CDI-142 > URL: https://issues.jboss.org/browse/CDI-142 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Stuart Douglas > Labels: F2F2016 > Fix For: TBD > > > For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-129: ------------------------------------- Labels: F2F2016 application-scoped visibility (was: application-scoped visibility) > Clarify behaviour of @ApplicationScoped in EARs > ----------------------------------------------- > > Key: CDI-129 > URL: https://issues.jboss.org/browse/CDI-129 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Contexts > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: F2F2016, application-scoped, visibility > Fix For: 2.0 (discussion) > > > Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file). > There is currently no specified CDI scope for providing a single shared instance for a whole EAR. > We could (ab-)use @Singleton for that, but this is currently not well defined at all. > Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Antoine Sabot-Durand updated CDI-78: ------------------------------------ Labels: F2F2016 (was: ) > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Labels: F2F2016 > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 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: ---------------------------------------- well a bit more than taste cause it implies how an application can test if CDI is there: is getCdi() enough or should it tries to call one CDI method too? Also not sure what "container" means in your comment, I see CDI as the CDI container handle so anything before is not really CDI (= the CDIProvider is a bridge to CDI but doesn't require CDI). That said agree we just need to make it clear. One point can maybe be to check the api jars out there and see if changing the impl isn't easier since people will maybe not upgrade their API :s. Also it viciously brings the question of the contextuality of CDIProvider which is maybe not something we want to "spec" yet (ie is the provider bound to an impl and one context once the lookup is done or is CDI only contextual?). > 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)

8 years, 4 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: ---------------------------------- bq. and fail on getBeanManager() only ..and also {{CDI.select()}}, {{CDI.destroy()}}, etc. For me the provider is responsible to lookup a "valid" container instance and it's useless to return an instance which would throw ISE on each invocation. But it's probably just a matter of taste ;-). The EG should decide... > 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)

8 years, 4 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 edited comment on CDI-626 at 8/24/16 8:39 AM: ----------------------------------------------------------------- Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you called "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name. was (Author: rmannibucau): Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you can "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name. > 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)

8 years, 4 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: ---------------------------------------- Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you can "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name. > 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)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2016