March 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-392: ----------------------------------- After quite some discussion I suppose we also move the barrier from AfterDeploymentValidation to AfterBeanDiscovery as already suggested in CDI-274. The whole goal of this Exception is to prevent random behaviour during bean scanning. And this is perfectly guaranteed if we prevent those methods until AfterBeanDiscovery. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

1
0
0 / 0

JSR-392

by Mark Struberg

Hi! I'm asking myself if forbiding various methods until AfterDeploymentValidation isn't a bit too tight. It does of course make no sense to call getBeans, etc until AfterBeanDiscovery. But it could make sense to allow it IN AfterBeansDiscovery. Of course, adding beans in ABD would need to reset some resolver-caches maybe (depends on the actual container implementation). But at least it would make sense and would be pretty predictiable (in contrast to calling getBeans _during_ the class-scanning). wdyt? LieGrue, strub

10 years

1
0
0 / 0

Finishing MR

by Antoine Sabot-Durand

Hi all, So we now have all the MR ticket processed. There’s still 3 ticket related PR pending on https://github.com/cdi-spec/cdi/pulls. We should close them by monday. PR for CDI-428 and CDI-331 should be fast to review, so please take a few minutes to do it. Mark, will you have time to work on CDI-392 before monday so we can close it ? I you don’t I’ll do it but let me know today please. Antoine

10 years

1
0
0 / 0

[JBoss JIRA] (CDI-428) Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-428?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-428: ------------------------------------- Assignee: Antoine Sabot-Durand > Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point > ------------------------------------------------------------------------------------------------------- > > Key: CDI-428 > URL: https://issues.jboss.org/browse/CDI-428 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.1.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > It should be more explicit that these behaves differently. The beginning of this possibility of confusion started with CDI-7. During CDI-422 resolution there was discussion about misunderstanding of these behavior. > Everybody agree with the current way it's working but the specification obviously of precision about these differences. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

1
0
0 / 0

[JBoss JIRA] (CDI-428) Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-428?page=com.atlassian.jira.plugin.sy... ] Work on CDI-428 started by Antoine Sabot-Durand. > Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point > ------------------------------------------------------------------------------------------------------- > > Key: CDI-428 > URL: https://issues.jboss.org/browse/CDI-428 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.1.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > It should be more explicit that these behaves differently. The beginning of this possibility of confusion started with CDI-7. During CDI-422 resolution there was discussion about misunderstanding of these behavior. > Everybody agree with the current way it's working but the specification obviously of precision about these differences. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

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... ] Work on CDI-220 stopped by Antoine Sabot-Durand. > 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 > Fix For: TBD > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

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: ------------------------------------- Fix Version/s: TBD (was: 1.2 Proposed) Depend on CDI-280 clarification that was postpone for 2.0 > 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 > Fix For: TBD > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

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: ------------------------------------- Assignee: Antoine Sabot-Durand > 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 > Fix For: 1.2 Proposed > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

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... ] Work on CDI-220 started by Antoine Sabot-Durand. > 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 > Fix For: 1.2 Proposed > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

1
0
0 / 0

[JBoss JIRA] (CDI-427) Review all annotations for inclusion to bean defining annotations

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-427?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-427. -------------------------------------- Resolution: Done After discussion, no annotation had to be added to the list. > Review all annotations for inclusion to bean defining annotations > ----------------------------------------------------------------- > > Key: CDI-427 > URL: https://issues.jboss.org/browse/CDI-427 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result. > Two candidates that come to mind are @Alternative and @Specializes. > This issue depends on the resolution of CDI-408 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2014