November 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Pete Muir (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Pete Muir reopened CDI-83: -------------------------- > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-58: ---------------------------------- If we would like to allow multiple AnnotatedTypes per class, then I think there are still 2 occurrences which in the spec which must get fixed: section 11.5.1 BeforeBeanDiscoveryEvent The container must fire an event before it begins the bean discovery process. The event object must be of type javax.enterprise.inject.spi.BeforeBeanDiscovery: This should mention the synthetical AnnotatedTypes section 11.3.17. Obtaining an AnnotatedType for a class The method BeanManager.createAnnotatedType(Class<T> type) returns an AnnotatedType that may be used to read the annotations of a given Java class or interface. In OWB we return the 'effective' AnnotatedType of a class. Means if you exchanged/modified the AnnotatedType in ProcessAnnoatedType, you will get the changed one. By allowing multiple AnnotatedTypes per class this is not possible anymore as it is ambiguous. > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Jozef Hartinger (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-52: ------------------------------------ Another conflict I run into: In order to preserve the InjectionPoint reference till the execution of a disposer method, it is necessary to keep the reference in the CreationalContext. However, the spec says: {quote} Producer.dispose() calls the disposer method, if any, on a contextual instance of the bean that declares the disposer method, as defined in Section 5.5.4, “Invocation of producer or disposer methods”, or performs any additional required cleanup, if any, to destroy state associated with a resource. {quote} which means that the invocation of the disposer method is managed by the dispose() method of the Producer interface. Since Producer is not aware of the CreationalContext associated with the instance being disposed, it itself cannot restore the InjectionPoint properly. > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-92) Allow injection of Bean object for a bean

by Jozef Hartinger (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-92: -------------------------------- Reopening, since multiple implications are not handled by this change. 1.) The qualifiers (@Intercepted, @Decorated) are missing from the API and from the specification document. 2.) Similarly to the Injection point metadata section, the Bean metadata section should name possible invalid scenarios and required the container to treat them as a definition error. These include: * Interceptor<?> injection point in a non-interceptor bean * @Intercepted Bean<?> injection point in a non-interceptor bean * Decorator<?> injection point in a non-decorator bean * @Decorated Bean<?> injection point in a non-decorator bean 3.) The spec should define what happens in the following scenatio: {code:JAVA} class Foo { @Inject Bean<Bar> metadata; } {code} Should the container validate the generic type of a bean metadata injection point? Should the abovementioned example be treated as a definiton error? 4.) The spec should perhaps explicitly state that it is possible to inject bean metadata into a disposer method and that this metadata always refers to the producer field/method that created the instance being destroyed. > Allow injection of Bean object for a bean > ----------------------------------------- > > Key: CDI-92 > URL: https://issues.jboss.org/browse/CDI-92 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Mark Struberg (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Mark Struberg reopened CDI-50: ------------------------------ Pete, not sure if we can do it this way. I'm concerned about @Requires(Foo.class) Because if Foo.class is not available, then what to compare?... This must either be a fully qualified className or we move all the '@Optional' stuff to the beans.xml. See CDI-35. > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-56) Clarify that scope types should not have members

by Martin Kouba (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-56?page=com.atlassian.jira.plugin.sys... ] Martin Kouba reopened CDI-56: ----------------------------- Clarify spec wording -> what happens in case of scope type has members. > Clarify that scope types should not have members > ------------------------------------------------ > > Key: CDI-56 > URL: https://issues.jboss.org/browse/CDI-56 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > The spec should mention that @NormalScope annotations should not have annotation members. Perhaps this should be a definition error. javax.inject.Scope already mentions this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-56) Clarify that scope types should not have members

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-56?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-56: ---------------------------------- Actually not sure if it might not be a cool feature. @WorkFlowScoped(CloseOnChange) public class MyWorkflowItem {... Of course we would need to clarify that @Nonbinding must get evaluated, etc Of course, I guess that no CDI container currently supports this ;) > Clarify that scope types should not have members > ------------------------------------------------ > > Key: CDI-56 > URL: https://issues.jboss.org/browse/CDI-56 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > The spec should mention that @NormalScope annotations should not have annotation members. Perhaps this should be a definition error. javax.inject.Scope already mentions this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-56) Clarify that scope types should not have members

by Martin Kouba (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-56?page=com.atlassian.jira.plugin.sys... ] Martin Kouba commented on CDI-56: --------------------------------- We should also clarify what happens if a scope type has members. I believe it's definition error in this case. > Clarify that scope types should not have members > ------------------------------------------------ > > Key: CDI-56 > URL: https://issues.jboss.org/browse/CDI-56 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > The spec should mention that @NormalScope annotations should not have annotation members. Perhaps this should be a definition error. javax.inject.Scope already mentions this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Jozef Hartinger (Updated) (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger updated CDI-52: ------------------------------- Fix Version/s: 1.1.EDR2 (was: 1.1.EDR1) > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Jozef Hartinger (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-52: -------------------------------- The spec says: {quote}An instance of InjectionPoint may represent: • an injected field or a *parameter* of a bean constructor, initializer method, producer method, disposer method or observ-er method, or • an instance obtained dynamically using Instance.get(). {quote} Besides fields and parameters, it does not mention other member types. However, later in the text, the spec clarifies: {quote}The InjectionPoint injected into a disposer method represents the producer method for which the disposer method is be- ing invoked. {quote} It is unclear how the producer method is represented by an InjectionPoint instance. > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2011