April 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-36) ObserverMethod.notify() does not forward qualifiers for Event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-36?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-36: ------------------------- Fix Version/s: 1.1.FD (was: 1.1.EDR) > ObserverMethod.notify() does not forward qualifiers for Event > ------------------------------------------------------------- > > Key: CDI-36 > URL: https://issues.jboss.org/browse/CDI-36 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Reporter: Jordan Ganoff > Assignee: Pete Muir > Fix For: 1.1.FD > > > There's currently no way to get the qualifiers for a fired event. ObserverMethod.notify() only passes the event object itself. Without the qualifiers it is difficult to bridge the gap between CDI events and some other event infrastructure (e.g. JMS). -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-289) Clarify what happens if a CDI-scoped stateful session bean is removed due to exception

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-289?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-289: -------------------------- Fix Version/s: (was: 1.1 (Proposed)) > Clarify what happens if a CDI-scoped stateful session bean is removed due to exception > -------------------------------------------------------------------------------------- > > Key: CDI-289 > URL: https://issues.jboss.org/browse/CDI-289 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Labels: faq > > {code:JAVA} > @ApplicationScoped > @Stateful > public class Foo { > ... > } > {code} > According to the EJB spec (4.6.2) the instance of Foo will be removed if a method invocation on Foo throws a runtime exception that is not an application exception. CDI should clarify if in that case a new instance of Foo replaces the old instance or whether the clients will keep receiving NoSuchEJBException for the rest of the application lifetime. -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-334) Issues with global enablement of alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-334?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-334. --------------------------- Resolution: Done Pushed this change. > Issues with global enablement of alternatives > --------------------------------------------- > > Key: CDI-334 > URL: https://issues.jboss.org/browse/CDI-334 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Resolution > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > * Section 5.1 last paragraph does not reflect global enablement of alternatives. > * Section 5.1.1 fails to define how @Priority relates to: > ** alternative stereotypes > ** producers > * Section 5.1.6 does not reflect global enablement of alternatives > Section 5.2.2: > ** generally the section needs to take global enablement of alternatives into account > ** "If all the beans left are alternatives with a priority, then the container will select the alternative with the highest priority, and the > ambiguous dependency is called resolvable." > *** there is no guarantee that there is a single alternative with the highest priority. The spec should define what happens in that case. > *** also, the statement should not only consider "alternatives" but also producers defined on alternatives > * Section 5.3.1 - same as 5.2.2 > * Recommended priority ranges for alternatives should be defined somewhere -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-334) Issues with global enablement of alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-334?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-334: ------------------------------- Text for resolving ambiguous dependencies changed to: {quote}When an ambiguous dependency exists, the container attempts to resolve the ambiguity. The container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If: there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable. all the beans left are alternatives with a priority, or producer methods or fields of beans that are alternatives with a priority, then the container will determine the highest priority value, and eliminate all beans, except for alternatives with the highest priority and producer methods and fields of alternatives with the highest priority value. If there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable.{quote} > Issues with global enablement of alternatives > --------------------------------------------- > > Key: CDI-334 > URL: https://issues.jboss.org/browse/CDI-334 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Resolution > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > * Section 5.1 last paragraph does not reflect global enablement of alternatives. > * Section 5.1.1 fails to define how @Priority relates to: > ** alternative stereotypes > ** producers > * Section 5.1.6 does not reflect global enablement of alternatives > Section 5.2.2: > ** generally the section needs to take global enablement of alternatives into account > ** "If all the beans left are alternatives with a priority, then the container will select the alternative with the highest priority, and the > ambiguous dependency is called resolvable." > *** there is no guarantee that there is a single alternative with the highest priority. The spec should define what happens in that case. > *** also, the statement should not only consider "alternatives" but also producers defined on alternatives > * Section 5.3.1 - same as 5.2.2 > * Recommended priority ranges for alternatives should be defined somewhere -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-274: ------------------------------- ABD is definitely too early, the bean graph is not fully built by then. The best we can do here is make this non-portable IMO. > BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation > ------------------------------------------------------------------------------------------ > > Key: CDI-274 > URL: https://issues.jboss.org/browse/CDI-274 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: faq > Fix For: 1.1.PFD > > > We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method. > Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs. > PROPOSAL: > We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error. -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-274: -------------------------- Fix Version/s: 1.1.FD (was: 1.1.PFD) > BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation > ------------------------------------------------------------------------------------------ > > Key: CDI-274 > URL: https://issues.jboss.org/browse/CDI-274 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: faq > Fix For: 1.1.FD > > > We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method. > Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs. > PROPOSAL: > We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error. -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ] Mark Struberg reopened CDI-274: ------------------------------- It seems we really need to move the barrier to AfterBeanDiscovery. I've now seen a few Extensions which use AfterBeanDiscovery and scan for certain types of Bean and call abd.addobserverMethod for them. > BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation > ------------------------------------------------------------------------------------------ > > Key: CDI-274 > URL: https://issues.jboss.org/browse/CDI-274 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: faq > Fix For: 1.1.PFD > > > We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method. > Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs. > PROPOSAL: > We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error. -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-36) ObserverMethod.notify() does not forward qualifiers for Event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-36?page=com.atlassian.jira.plugin.sys... ] Pete Muir reopened CDI-36: -------------------------- This change got backed out. Lincoln has an alternate proposal https://github.com/jboss/cdi/pull/187 > ObserverMethod.notify() does not forward qualifiers for Event > ------------------------------------------------------------- > > Key: CDI-36 > URL: https://issues.jboss.org/browse/CDI-36 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Reporter: Jordan Ganoff > Assignee: Pete Muir > Fix For: 1.1.EDR > > > There's currently no way to get the qualifiers for a fired event. ObserverMethod.notify() only passes the event object itself. Without the qualifiers it is difficult to bridge the gap between CDI events and some other event infrastructure (e.g. JMS). -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-361. --------------------------- Resolution: Done Thanks, I've added validation that interceptors are passivation capable to the list. > Issues with passivation capable beans and dependencies > ------------------------------------------------------ > > Key: CDI-361 > URL: https://issues.jboss.org/browse/CDI-361 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > h3. Dependencies of interceptors and decorators: > {quote} > If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean: > * is not passivation capable, > * has a non-transient injected field, bean constructor parameter or initializer method parameter which is not annotated with @TransientReference and that resolves to a dependent scoped bean that is not a passivation capable dependency, or > * has a non-transient injected field, bean constructor parameter or initializer method parameter that resolves to a bean that is not > a dependent scoped bean and that is not a passivation capable dependency, or > * has an interceptor or decorator with a non-transient injected field that does not resolve to a passivation capable dependency, > then the container automatically detects the problem and treats it as a deployment problem. > {quote} > It is not enough to validate injected fields of interceptors/decorators only. The specification should require validation of *all* injection points of an interceptor / decorator also considering @TransientReference > h3. Decorators of built-in beans should be passivation capable > {quote}If a managed bean or a stateful session bean which declares a passivating scope type, has a decorator or interceptor which is not > a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem.{quote} > Combined with the quote above the specification only requires injection points of a decorator of a built-in bean to be passivation capable dependencies. The specification should also require the decorators themselves to be passivation capable dependencies. -- 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

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-357) @Stateless and @Singleton session beans are no longer passivation capable dependencies

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-357?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-357. --------------------------- Resolution: Done Thanks, I've made those changes, and also changed the line about SLSBs and singletons to be about a single bean, not all beans, to be consistent with the whole text. > @Stateless and @Singleton session beans are no longer passivation capable dependencies > -------------------------------------------------------------------------------------- > > Key: CDI-357 > URL: https://issues.jboss.org/browse/CDI-357 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > This is a regression since 1.0 > CDI 1.0: > {quote}all session beans are passivation capable dependencies{quote} > CDI 1.1: > {quote}all passivation capable beans with scope @Dependent are passivation capable dependencies{quote} > and > {quote}As defined by the EJB specification, stateless and singleton session beans are not passivation capable{quote} -- 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

11 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2013