September 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Commented: (CDI-61) Producers and beans that are under construction

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-61?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-61: ------------------------------ We should make this cause an exception. > Producers and beans that are under construction > ----------------------------------------------- > > Key: CDI-61 > URL: https://issues.jboss.org/browse/CDI-61 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-77) Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-77?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-77: ------------------------------ The preamble to section 5 mentions that recursive unbound injections with dependent scoped beans need not be supported, but doesn't repeat this exact phrase in the chapter body (the preamble in the CDI spec is normally considered somewhat non-normative). Move this to the spec body, and make it a definition exception. > Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans > ---------------------------------------------------------------------------------------------------- > > Key: CDI-77 > URL: https://issues.jboss.org/browse/CDI-77 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > for example > class Foo { > @Inject Bar bar; > } > class bar { > @Inject Foo foo; > } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-39) Add a standard format for defining metadata about extensions

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-39?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-39: ------------------------- Description: Build on the support introduced for Manifests in CDI-163 and specify some standard keys: * id * description * version Add a non-normative note that an impl may wish to use this information and log what extensions are present. was:e.g. add optional name, description and version fields to an optional annotation. Makes it easy for modules to track what is being loaded > Add a standard format for defining metadata about extensions > ------------------------------------------------------------ > > Key: CDI-39 > URL: https://issues.jboss.org/browse/CDI-39 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Build on the support introduced for Manifests in CDI-163 and specify some standard keys: > * id > * description > * version > Add a non-normative note that an impl may wish to use this information and log what extensions are present. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (CDI-163) Add support injecting Manifest object for JAR defining class

by Pete Muir (JIRA)

Add support injecting Manifest object for JAR defining class ------------------------------------------------------------ Key: CDI-163 URL: https://issues.jboss.org/browse/CDI-163 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir Fix For: 1.1 (Proposed) Currently accessing the Manifest for a class is a nightmare in Java. As CDI knows more about app structure it's not such a problem. Support a built in bean of type Manifest with qualifiers @Default that is the Manifest for the JAR file which defines the class (as determined by the Jar file spec). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (CDI-42) Allow you to inject the intercepted bean into an Interceptor

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-42?page=com.atlassian.jira.plugin.sys... ] Pete Muir reassigned CDI-42: ---------------------------- Assignee: Marius Bogoevici > Allow you to inject the intercepted bean into an Interceptor > ------------------------------------------------------------ > > Key: CDI-42 > URL: https://issues.jboss.org/browse/CDI-42 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (CDI-49) The availability of the BeanManager should follow the normal EE visibility rules

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-49?page=com.atlassian.jira.plugin.sys... ] Pete Muir closed CDI-49. ------------------------ Assignee: Pete Muir Fix Version/s: (was: 1.1 (Proposed)) Resolution: Duplicate Issue > The availability of the BeanManager should follow the normal EE visibility rules > -------------------------------------------------------------------------------- > > Key: CDI-49 > URL: https://issues.jboss.org/browse/CDI-49 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration, Packaging and Deployment, Resolution > Affects Versions: 1.0 > Environment: JSR-000316 Java Platform, Enterprise Edition 6 Specification > Reporter: Aslak Knutsen > Assignee: Pete Muir > > EE 6 spec > EE.5.19 > A bean manager is only available in modules in which CDI has been enabled. > In e.g. a EAR deployment, a WAR module can see a EJB module. With CDI enabled in the EJB, the WAR can only see the BeanManager if the WAR itself is also CDI enabled. In cases where you want to do dynamic introspection of available beans etc, this is a bit cumbersome, especially since the introspecting code can be in a packaged jar inside a unknown WAR.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-84) Non EE modules should be able to inject/lookup in JNDI a BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-84: ------------------------- Summary: Non EE modules should be able to inject/lookup in JNDI a BeanManager (was: Non EE modules should be able to trigger creation of a BeanManager) > Non EE modules should be able to inject/lookup in JNDI a BeanManager > -------------------------------------------------------------------- > > Key: CDI-84 > URL: https://issues.jboss.org/browse/CDI-84 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Fix For: 1.1 (Proposed) > > > EE.5.19 > A bean manager is only available in modules in which CDI has been enabled. > Where EE modules are defined to be; ejb-jar, rar, client jar and war. > This is a missmatch between the EE spec and the CDI spec. According to the CDI spec, any archive with a beans.xml is defined as a BeanArchive and should be included in a BeanManager, EE define it to be only EE modules should trigger BeanManager creation. > Opening this up to follow the CDI spec will let any library use the BeanManager to introspect other BeanArchives without having to involve the owning EE module in the loop. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-84) Non EE modules should be able to trigger creation of a BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-84: ------------------------- Issue Type: Tracker (was: Feature Request) > Non EE modules should be able to trigger creation of a BeanManager > ------------------------------------------------------------------ > > Key: CDI-84 > URL: https://issues.jboss.org/browse/CDI-84 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Fix For: 1.1 (Proposed) > > > EE.5.19 > A bean manager is only available in modules in which CDI has been enabled. > Where EE modules are defined to be; ejb-jar, rar, client jar and war. > This is a missmatch between the EE spec and the CDI spec. According to the CDI spec, any archive with a beans.xml is defined as a BeanArchive and should be included in a BeanManager, EE define it to be only EE modules should trigger BeanManager creation. > Opening this up to follow the CDI spec will let any library use the BeanManager to introspect other BeanArchives without having to involve the owning EE module in the loop. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] Pete Muir updated CDI-2: ------------------------ Fix Version/s: 1.1 (Confirmed) (was: 1.1 (Proposed)) Affects Version/s: (was: 1.0) Component/s: Inheritance and Specialization (was: Interceptors) > Interceptor bindings defined at method level should override those at the class level > ------------------------------------------------------------------------------------- > > Key: CDI-2 > URL: https://issues.jboss.org/browse/CDI-2 > Project: CDI Specification Issues > Issue Type: Bug > Components: Inheritance and Specialization > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Confirmed) > > > Gavin said: > "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec." > In section 9.5.2 of the spec: > If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

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

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-50: ------------------------- Fix Version/s: 1.1 (Confirmed) (was: 1.1 (Proposed)) Git Pull Request: https://github.com/jboss/cdi/pull/52 (was: https://github.com/jboss/cdi/pull/52) Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2009-December/002029.html (was: http://lists.jboss.org/pipermail/weld-dev/2009-December/002029.html) > 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 > Fix For: 1.1 (Confirmed) > > > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2011