March 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-324) Update InjectionPoint getBean() and isTransient() methods description to reflect Event instance

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-324?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-324: ------------------------------- * getBean() {quote} The getBean() method returns the Bean object representing the bean that defines the injection point. If the injection point does not belong to a bean, getBean() returns a null value. If the injection point represents a dynamically obtained instance *or event*, the getBean() method should return the Bean object representing the bean that defines the Instance injection point. {quote} (see my emphasis) * isTransient() {quote} The isTransient() method returns true if the injection point is a transient field, and false otherwise. If the injection point represents a dynamically obtained instance *or event* then the isTransient() method returns true if the Instance injection point is a transient field, and false otherwise. {quote} > Update InjectionPoint getBean() and isTransient() methods description to reflect Event instance > ----------------------------------------------------------------------------------------------- > > Key: CDI-324 > URL: https://issues.jboss.org/browse/CDI-324 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.FD > > > Also update {{javax.enterprise.inject.spi.InjectionPoint}} javadoc. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-331) Instance.iterator() shouldn't include disabled alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-331: -------------------------- Summary: Instance.iterator() shouldn't include disabled alternatives (was: Clarify Instance.iterator()) Issue Type: Feature Request (was: Clarification) Fix Version/s: TBD (was: 1.1.FD) Description: The specification currently says that: {quote} The iterator() method must: • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1. {quote} The ambiguity resolution algorithm as defined in 5.2.2 should be applied. This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency: Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative. Assume further the following {noformat} @Inject @Any Instance<Common> instance {noformat} injection point. was: The specification currently says that: {quote} The iterator() method must: • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1. {quote} The question that arises is whether the implementation should apply ambiguity resolution algorithm as defined in 5.2.2 or not. This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency: Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative. Assume further the following {noformat} @Inject @Any Instance<Common> instance {noformat} injection point. It is clear that instance.get() returns Bar. It is however not clear whether instance.iterator() iterates over: a) Bar b) Foo, Bar and whether instance.isAmbiguous() returns: a) true b) false > Instance.iterator() shouldn't include disabled alternatives > ----------------------------------------------------------- > > Key: CDI-331 > URL: https://issues.jboss.org/browse/CDI-331 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: TBD > > > The specification currently says that: > {quote} > The iterator() method must: > • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into > which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1. > {quote} > The ambiguity resolution algorithm as defined in 5.2.2 should be applied. > This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency: > Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative. > Assume further the following > {noformat} > @Inject @Any Instance<Common> instance > {noformat} > injection point. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-333) Treatment of exceptions raised during container lifecycle event notification inconsistent

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-333?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-333. --------------------------- Resolution: Done Done > Treatment of exceptions raised during container lifecycle event notification inconsistent > ----------------------------------------------------------------------------------------- > > Key: CDI-333 > URL: https://issues.jboss.org/browse/CDI-333 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > If an exception is raised by extension during container lifecycle event notification this exception is treated either as a definition or a deployment problem. > Definition problems: > * BeforeBeanDiscovery > * AfterBeanDiscovery > * ProcessAnnotatedType > * ProcessInjectionPoint > * ProcessInjectionTarget > * ProcessProducer > * ProcessBeanAttributes > * ProcessBean > * ProcessObserverMethod > Deployment problems: > * AfterTypeDiscovery > * AfterDeploymentValidation > AfterTypeDiscovery seems to be the odd one out as the event is fired between BBD and ABD which both treat extension exceptions as definition errors. -- 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

12 years, 7 months

1
0
0 / 0

CDI-324

by Martin Kouba

FYI, I raised a minor clarification issue: https://issues.jboss.org/browse/CDI-324 Section: 5.5.7 Injection point metadata Issue: incomplete method description and javadoc M

12 years, 7 months

2
3
0 / 0

[JBoss JIRA] (CDI-326) Move isNullable() text to javax.enterprise.inject.spi.Bean description

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-326?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-326: -------------------------- Fix Version/s: 1.1.FD > Move isNullable() text to javax.enterprise.inject.spi.Bean description > ---------------------------------------------------------------------- > > Key: CDI-326 > URL: https://issues.jboss.org/browse/CDI-326 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.FD > > -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-325) The spec text contains BeforeDeploymentValidation event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-325?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-325. --------------------------- Assignee: Pete Muir Resolution: Done Thanks, fixed. > The spec text contains BeforeDeploymentValidation event > ------------------------------------------------------- > > Key: CDI-325 > URL: https://issues.jboss.org/browse/CDI-325 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.FD > > -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-332) Broken example for obtaining unmanaged instance

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-332?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-332: -------------------------- Fix Version/s: 1.1.FD > Broken example for obtaining unmanaged instance > ----------------------------------------------- > > Key: CDI-332 > URL: https://issues.jboss.org/browse/CDI-332 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Priority: Minor > Fix For: 1.1.FD > > > The example in the spec text and javadoc: > {code} > Unmanaged unmanagedFoo = new Unmanaged(Foo.class); > UnmanagedInstance fooInstance = unManagedFoo.newInstance(); > Foo foo = fooInstance.produce().inject().postConstruct(); > // Use the foo instance > fooInstance.preDestroy().dispose(); > {code} > should be replaced with something like this: > {code} > Unmanaged<Foo> unmanagedFoo = new Unmanaged<Foo>(Foo.class); > UnmanagedInstance<Foo> fooInstance = unmanagedFoo.newInstance(); > Foo foo = fooInstance.produce().inject().postConstruct().get(); > // Use the foo instance > fooInstance.preDestroy().dispose(); > {code} > Note the generics, unManagedFoo -> unmanagedFoo and missing {{get()}}. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-332) Broken example for obtaining unmanaged instance

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-332?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-332. --------------------------- Assignee: Pete Muir Resolution: Done Thanks, fixed. > Broken example for obtaining unmanaged instance > ----------------------------------------------- > > Key: CDI-332 > URL: https://issues.jboss.org/browse/CDI-332 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.FD > > > The example in the spec text and javadoc: > {code} > Unmanaged unmanagedFoo = new Unmanaged(Foo.class); > UnmanagedInstance fooInstance = unManagedFoo.newInstance(); > Foo foo = fooInstance.produce().inject().postConstruct(); > // Use the foo instance > fooInstance.preDestroy().dispose(); > {code} > should be replaced with something like this: > {code} > Unmanaged<Foo> unmanagedFoo = new Unmanaged<Foo>(Foo.class); > UnmanagedInstance<Foo> fooInstance = unmanagedFoo.newInstance(); > Foo foo = fooInstance.produce().inject().postConstruct().get(); > // Use the foo instance > fooInstance.preDestroy().dispose(); > {code} > Note the generics, unManagedFoo -> unmanagedFoo and missing {{get()}}. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-326) Move isNullable() text to javax.enterprise.inject.spi.Bean description

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-326?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-326. --------------------------- Assignee: Pete Muir Resolution: Done Thanks, fixed. > Move isNullable() text to javax.enterprise.inject.spi.Bean description > ---------------------------------------------------------------------- > > Key: CDI-326 > URL: https://issues.jboss.org/browse/CDI-326 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Pete Muir > -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-333) Treatment of exceptions raised during container lifecycle event notification inconsistent

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-333: ----------------------------------- Summary: Treatment of exceptions raised during container lifecycle event notification inconsistent Key: CDI-333 URL: https://issues.jboss.org/browse/CDI-333 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.1.PFD Reporter: Jozef Hartinger Assignee: Pete Muir Fix For: 1.1.FD If an exception is raised by extension during container lifecycle event notification this exception is treated either as a definition or a deployment problem. Definition problems: * BeforeBeanDiscovery * AfterBeanDiscovery * ProcessAnnotatedType * ProcessInjectionPoint * ProcessInjectionTarget * ProcessProducer * ProcessBeanAttributes * ProcessBean * ProcessObserverMethod Deployment problems: * AfterTypeDiscovery * AfterDeploymentValidation AfterTypeDiscovery seems to be the odd one out as the event is fired between BBD and ABD which both treat extension exceptions as definition errors. -- 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

12 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2013