March 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-359) @Priority annotation is not defined in the CDI spec

by Marina Vatkina (JIRA)

Marina Vatkina created CDI-359: ---------------------------------- Summary: @Priority annotation is not defined in the CDI spec Key: CDI-359 URL: https://issues.jboss.org/browse/CDI-359 Project: CDI Specification Issues Issue Type: Bug Components: Interceptors Affects Versions: 1.1.PFD Reporter: Marina Vatkina on p.45 and p78: "The @Priority annotation, introduced in Contexts and Dependency Injection 1.1" - it was but not any more -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-227?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-227: ----------------------------- Priority: Blocker (was: Major) > BeanManager#resolve() is underspecified for corner cases > -------------------------------------------------------- > > Key: CDI-227 > URL: https://issues.jboss.org/browse/CDI-227 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration, Packaging and Deployment > Affects Versions: 1.0, 1.1.EDR > Reporter: Guy Veraghtert > Assignee: Pete Muir > Priority: Blocker > Labels: patch > Fix For: 1.1.FD > > > The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. > For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. > To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). > Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... > Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. > These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-227?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-227: ----------------------------- Fix Version/s: 1.1.FD (was: 1.1.PFD) > BeanManager#resolve() is underspecified for corner cases > -------------------------------------------------------- > > Key: CDI-227 > URL: https://issues.jboss.org/browse/CDI-227 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration, Packaging and Deployment > Affects Versions: 1.0, 1.1.EDR > Reporter: Guy Veraghtert > Assignee: Pete Muir > Labels: patch > Fix For: 1.1.FD > > > The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. > For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. > To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). > Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... > Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. > These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-227?page=com.atlassian.jira.plugin.sy... ] Martin Kouba reopened CDI-227: ------------------------------ BeanManager.resolve() javadoc still contains reference to module resolution: {quote} @returns the resolved bean, or null if no bean could be resolved, or null if null or an empty set is passed {quote} should be: {quote} @returns the resolved bean, or null if null or an empty set is passed {quote} > BeanManager#resolve() is underspecified for corner cases > -------------------------------------------------------- > > Key: CDI-227 > URL: https://issues.jboss.org/browse/CDI-227 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration, Packaging and Deployment > Affects Versions: 1.0, 1.1.EDR > Reporter: Guy Veraghtert > Assignee: Pete Muir > Labels: patch > Fix For: 1.1.PFD > > > The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. > For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. > To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). > Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... > Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. > These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-358) Ambiguous restrictions in javadoc for BM.getReference() and BM.getInjectableReference()

by Martin Kouba (JIRA)

Martin Kouba created CDI-358: -------------------------------- Summary: Ambiguous restrictions in javadoc for BM.getReference() and BM.getInjectableReference() Key: CDI-358 URL: https://issues.jboss.org/browse/CDI-358 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Assignee: Pete Muir Priority: Minor Fix For: 1.1.FD {{BeanManager.getReference()}} and {{BeanManager.getInjectableReference()}} javadoc states {quote} Non-portable behavior results if called during application initialization. {quote} and {quote} IllegalStateException if called during application initialization, before the AfterDeploymentValidation event is fired {quote} in the same time. -- 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, 7 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-357: ----------------------------------- Summary: @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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-344) bean-discovery-mode should be specified

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-344?page=com.atlassian.jira.plugin.sy... ] Martin Kouba edited comment on CDI-344 at 3/18/13 11:46 AM: ------------------------------------------------------------ -I think the spec should also explicitly define that all *explicit bean archives* result in {{bean-discovery-mode="all"}} behaviour (that's the way I understand it...).- This is already covered in section 12.4 "Bean discovery". was (Author: mkouba): I think the spec should also explicitly define that all *explicit bean archives* result in {{bean-discovery-mode="all"}} behaviour (that's the way I understand it...). > bean-discovery-mode should be specified > --------------------------------------- > > Key: CDI-344 > URL: https://issues.jboss.org/browse/CDI-344 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > It seems that the only complete source of information about the *bean-discovery-mode* attribute is the schema file. The specification should better explain the attribute, list and explain allowed values. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-355) Disconnect between other specs and CDI with regard to when Interceptors and decorators are run

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-355?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-355: -------------------------- Fix Version/s: 1.1.FD > Disconnect between other specs and CDI with regard to when Interceptors and decorators are run > ---------------------------------------------------------------------------------------------- > > Key: CDI-355 > URL: https://issues.jboss.org/browse/CDI-355 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Joe Bergmark > Fix For: 1.1.FD > > > Other specifications have text that appears to assume interceptors will run for non-contextual instances. > The PDF (and CDI 1.0 for that matter) list the following rules to be considered a business method: > 7.2 > Container invocations and interception [biz_method] > When the application invokes: > • a method of a bean via a contextual reference to the bean, as defined in Section 6.5.3, or > • a business method of a session bean via an EJB remote or local reference, > and then say: > If, and only if, an invocation is a business method invocation: > • it passes through method interceptors and decorators, and > • in the case of a session bean, it is subject to EJB services such as declarative transaction management, concurrency, security > and asynchronicity, as defined by the EJB specification. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-356) Constructor-level interceptor bindings not considered

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-356: ----------------------------------- Summary: Constructor-level interceptor bindings not considered Key: CDI-356 URL: https://issues.jboss.org/browse/CDI-356 Project: CDI Specification Issues Issue Type: Bug Components: Interceptors Affects Versions: 1.1.PFD Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Blocker Fix For: 1.1.FD For example: {quote} If an interceptor for lifecycle callbacks declares an interceptor binding type that not defined @Target(TYPE), the container automatically detects the problem and treats it as a definition error. {quote} An interceptor that declares an @AroundConstruct interceptor method is an interceptor for a lifecycle callback yet it makes sense to define the binding as @Target(CONSTRUCTOR). -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-355) Disconnect between other specs and CDI with regard to when Interceptors and decorators are run

by Joe Bergmark (JIRA)

Joe Bergmark created CDI-355: -------------------------------- Summary: Disconnect between other specs and CDI with regard to when Interceptors and decorators are run Key: CDI-355 URL: https://issues.jboss.org/browse/CDI-355 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.PFD Reporter: Joe Bergmark Other specifications have text that appears to assume interceptors will run for non-contextual instances. The PDF (and CDI 1.0 for that matter) list the following rules to be considered a business method: 7.2 Container invocations and interception [biz_method] When the application invokes: • a method of a bean via a contextual reference to the bean, as defined in Section 6.5.3, or • a business method of a session bean via an EJB remote or local reference, and then say: If, and only if, an invocation is a business method invocation: • it passes through method interceptors and decorators, and • in the case of a session bean, it is subject to EJB services such as declarative transaction management, concurrency, security and asynchronicity, as defined by the EJB specification. -- 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, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2013