December 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-188) Bean in different wars should be allowed to have the same EL name

by Stuart Douglas (Created) (JIRA)

Bean in different wars should be allowed to have the same EL name ----------------------------------------------------------------- Key: CDI-188 URL: https://issues.jboss.org/browse/CDI-188 Project: CDI Specification Issues Issue Type: Bug Reporter: Stuart Douglas Normally two beans with the same @Named would be treated as an error. If they are in sperate war's this should be allowed. -- 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

11 years, 8 months

6
11
0 / 0

[JBoss JIRA] Created: (CDI-149) AnnotationLiteral in the CDI API does not cache the hashCode

by Stuart Douglas (JIRA)

AnnotationLiteral in the CDI API does not cache the hashCode ------------------------------------------------------------ Key: CDI-149 URL: https://issues.jboss.org/browse/CDI-149 Project: CDI Specification Issues Issue Type: Bug Reporter: Stuart Douglas Instead it is calculated each time using reflection, which could result in performance problems if lots of annotation literals are in use -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
6
0 / 0

[JBoss JIRA] (CDI-202) Clarify when BeanManager.createBeanAttributes(AnnotatedMember) returns an alternative

by Jozef Hartinger (Created) (JIRA)

Clarify when BeanManager.createBeanAttributes(AnnotatedMember) returns an alternative ------------------------------------------------------------------------------------- Key: CDI-202 URL: https://issues.jboss.org/browse/CDI-202 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) Currently, a producer field/method is an alternative if it is annotated with @Alternative or an alternative stereotype or the class declaring the field/method is annotated this way. However, when the BeanManager.createBeanAttributes(AnnotatedMember) method is called, the container has no access to the bean that declares the member. Therefore, the specification should clarify whether the container * should examine the AnnotatedType for @Alternative or alternative stereotypes * should try to infer the declaring bean (probably not possible since multiple beans may exist, each of them possibly modified in the ProcessBeanAttributes phase, etc.) * should make an assumption (e.g. the bean that declares the returned BeanAttributes is always assumed not to be an alternative) -- 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

11 years, 8 months

3
2
0 / 0

[JBoss JIRA] (CDI-204) Clarify ProcessInjectionPoint type parameters

by Jozef Hartinger (Created) (JIRA)

Clarify ProcessInjectionPoint type parameters --------------------------------------------- Key: CDI-204 URL: https://issues.jboss.org/browse/CDI-204 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) {quote} The container must fire an event for every injection point of every Java EE component class supporting injection that may be instantiated by the container at runtime. The event object must be of type javax.enterprise.inject.spi.ProcessInjectionPoint<T,X> where T is the bean class of the bean that declares the injection point, and X is the declared type of the injection point. {quote} The first paragraph implies that this event may be fired for injection points not necesarilly defined on a bean. In that case, the value of the T type parameter is unclear. -- 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

11 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-152) Access the the web.xml from CDI extensions

by Brian Leathem (JIRA)

Access the the web.xml from CDI extensions ------------------------------------------ Key: CDI-152 URL: https://issues.jboss.org/browse/CDI-152 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Brian Leathem Currently it is not possible to access the web.xml file from CDI extensions in a portable way, since the ServletContext is not available from CDI extensions (at least in EE enviroments). I filed a Servlet spec issue to make the web.xml file accessible, prior to the the ServletContext being initialized: http://java.net/jira/browse/SERVLET_SPEC-9 Perhaps as an alternative solution, CDI could do something to delay CDI extensions from loading until the ServletContext is available? Since this is the case for Servlet environments, would it not be acceptable for EE environments as well? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
3
0 / 0

[JBoss JIRA] (CDI-182) Cluster Lifecycle Events

by Kristoffer Sjögren (Created) (JIRA)

Cluster Lifecycle Events ------------------------ Key: CDI-182 URL: https://issues.jboss.org/browse/CDI-182 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Affects Versions: 1.1 (Proposed) Environment: Any java environment. Reporter: Kristoffer Sjögren Priority: Minor Fix For: 1.1 (Proposed) CDI 1.1 defines a set of lifecycle events related to different context within the application. We see a need to also define cluster lifecycle events for applications. These events could, for example, be used for subscribing/allocating and unsubscribing/deallocating external services/resources. More specifically, a @Cluster event that gets fired when an application gets @Initialized in the cluster, that is, post @Application @Initialized. And another @Cluster event that gets fired when the application get @Destroyed in the cluster, that is, pre @Application @Destroyed. These events only fires once per application and cluster, independent on how many cluster instances exists. Events are fault tolerant meaning that events are not affected by failing instances going out-of-service, as long as the cluster is still working. Notice that the @Destroyed event is of course only invoked if the cluster terminates gracefully. -- 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

11 years, 8 months

2
1
0 / 0

[JBoss JIRA] (CDI-198) Make beans.xml validation consistent with the ProcessModule event

by Jozef Hartinger (Created) (JIRA)

Make beans.xml validation consistent with the ProcessModule event ----------------------------------------------------------------- Key: CDI-198 URL: https://issues.jboss.org/browse/CDI-198 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) The validation of enabled interceptors, alternatives and decorators is currently tightly related to the beans.xml file, e.g.: {quote}If the same class is listed twice under the <interceptors> element, the container automatically detects the problem and treats it as a deployment problem.{quote} With CDI-97 in place, which allows extensions to change the enabled alternatives, decorators and interceptors, this is no longer sufficient. IMO, the validation of enabled interceptors and decorators should be the following: 1.) For each deployment descriptor, the container verifies that it does not contain duplicate interceptors, decorators or alternatives. 2.) For each BDA, the container fires the ProcessModule event allowing extensions to modify enabled alternatives, interceptors and decorators. 3.) For each BDA, the container verifies that the resulting collection of enabled alternatives, decorators and interceptors does not contain duplicates. The step 1.) is not actually necessary but may be convenient. -- 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

11 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (CDI-121) TransactionScope

by Richard Hightower (JIRA)

TransactionScope ---------------- Key: CDI-121 URL: https://issues.jboss.org/browse/CDI-121 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 1.1 (Proposed) Environment: Java EE Reporter: Richard Hightower Priority: Minor Add TransctionalScope as a standard scope to define beans whose lifecycle is the same as a given transaction. This scope should start automatically when a transaction starts (but lazily when actually needed). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

14
47
0 / 0

[JBoss JIRA] Created: (CDI-166) Disallow self consuming producers

by Martin Kouba (JIRA)

Disallow self consuming producers --------------------------------- Key: CDI-166 URL: https://issues.jboss.org/browse/CDI-166 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.0 Reporter: Martin Kouba Explicitly dissallow circular dependency in producers. That means bean which declares a producer and injects the result of that producer into the producer is not legal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
6
0 / 0

[JBoss JIRA] (CDI-189) Event qualifiers - empty set

by Jozef Hartinger (Created) (JIRA)

Event qualifiers - empty set ---------------------------- Key: CDI-189 URL: https://issues.jboss.org/browse/CDI-189 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 1.1.EDR1, 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1.EDR2 The spec says: {quote} An event comprises: * A Java object—the event object * A (*possibly empty*) set of instances of qualifier types—the event qualifiers {quote} while at the same it says that: {quote} *Every* event has the qualifier @javax.enterprise.inject.Any, even if it does not explicitly declare this qualifier. {quote} which impliest that a set of qualifiers of an event cannot be empty. -- 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

11 years, 8 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2011