July 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-103) Support client controlled contexts

by Pete Muir (JIRA)

Support client controlled contexts ---------------------------------- Key: CDI-103 URL: https://issues.jboss.org/browse/CDI-103 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir In a client controlled context, the client controls via some identifier (probably an identifier, but we should allow the context to inspect the injection point) which contextual instances it sees for a particular bean type. For example given: {code} @MyScope class Foo { String name; } {code} and a context which uses annotations to differentiate between contextual instance, these two injection points would see different instances: {code} @Inject @Bar Foo barFoo; @Inject @Baz Foo bazFoo; {code} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (CDI-143) Add a Util.getAnnotation(Member, Class<? extends Annotation>) style method

by Pete Muir (JIRA)

Add a Util.getAnnotation(Member, Class<? extends Annotation>) style method -------------------------------------------------------------------------- Key: CDI-143 URL: https://issues.jboss.org/browse/CDI-143 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) This would return information including stereotype information and is useful for other specs or frameworks to integrate with CDI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (CDI-109) Invalid beans should not be injectable into extensions

by John Ament (JIRA)

Invalid beans should not be injectable into extensions ------------------------------------------------------ Key: CDI-109 URL: https://issues.jboss.org/browse/CDI-109 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Currently, you can inject beans that may not be ready yet into the extension's call back methods. As an example, I can inject something application scoped like this in to an extension, but it should really be throwing a definition exception (or similar): public void handleABD(@Observes AfterBeanDiscovery abd, MyApplicationScopedBean masb) { } Pete had noted that really the only safe thing to inject, other than the observed call back, is the bean manager. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

10
18
0 / 0

[JBoss JIRA] Created: (CDI-144) Support Injection into Entity Listeners

by Cody Lerum (JIRA)

Support Injection into Entity Listeners --------------------------------------- Key: CDI-144 URL: https://issues.jboss.org/browse/CDI-144 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Cody Lerum It would be very convenient if CDI was available inside JPA Entity Listeners. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

6
15
0 / 0

[JBoss JIRA] Created: (CDI-112) Clarify how alternatives are enabled

by Shane Bryzak (JIRA)

Clarify how alternatives are enabled ------------------------------------ Key: CDI-112 URL: https://issues.jboss.org/browse/CDI-112 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Affects Versions: 1.0 Reporter: Shane Bryzak The spec is open to interpretation about how alternatives are enabled. One popular interpretation is that alternatives must be enabled within the same bean archive that contains the alternative bean. However, it might be worth considering the merit of enabling an alternative from a deployment archive that contains the bean archive. For example, suppose we have the following deployment archive: foo.war /WEB-INF beans.xml /lib bar.jar /META-INF beans.xml /com /acme AlternativeBean.class It may be worth allowing AlternativeBean.class (a class annotated with @Alternative) to be enabled by listing it in the <alternatives> section of foo.war/WEB-INF/beans.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
8
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-114) Allow registration of beans at runtime

by Vincent Massol (JIRA)

Allow registration of beans at runtime -------------------------------------- Key: CDI-114 URL: https://issues.jboss.org/browse/CDI-114 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 1.0 Reporter: Vincent Massol I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

8
13
0 / 0

calling 'equals' on a proxy?

by Mark Struberg

Hi Pete, others! Do you remember our discussion about what should happen if equals() gets called on a proxy? Should it route to the equals method of the currently proxied instance? LieGrue, strub

12 years, 6 months

7
18
0 / 0

[JBoss JIRA] Created: (CDI-140) improve Serializable requirements for @Dependent scoped beans in 6.6.4

by Mark Struberg (JIRA)

improve Serializable requirements for @Dependent scoped beans in 6.6.4 ---------------------------------------------------------------------- Key: CDI-140 URL: https://issues.jboss.org/browse/CDI-140 Project: CDI Specification Issues Issue Type: Clarification Components: Resolution Affects Versions: 1.0 Reporter: Mark Struberg Fix For: 1.1 (Proposed) Currently section 6.6.4 defines that @Dependent scoped beans which get injected into a bean of a passivating scope must be Serializable. "If a producer method or field of scope @Dependent returns an unserializable object for injection into an injection point that requires a passivation capable dependency, the container must throw an Illegal- ProductException" The question is how to interpret "that requires a passivation capable dependency". It would e.g. be perfectly fine if the @Dependent bean is _not_ Serializable *if* the injectionpoint will be serialized via a writeObject or Externalizable#writeExternal. Proposal: to explicitly add a check for Modifier.TRANSIENT and writeObject(ObjectOutputStream) and Externalizable#writeExternal(ObjectOutput) This is very important for @Dependent scoped producers of legacy classes because there is otherwise no way to inject such classes at all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (CDI-118) Standardize deployment-related exception classes

by Dan Allen (JIRA)

Standardize deployment-related exception classes ------------------------------------------------ Key: CDI-118 URL: https://issues.jboss.org/browse/CDI-118 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Affects Versions: 1.0 Reporter: Dan Allen Fix For: 1.1 (Proposed) While it's true that deployment exceptions are not a public API when developing with the CDI programming model, they are a public API for tools and in testing environments. It would be useful to standardize the deployment-related error and exception classes so that these tools don't have to rely on classes from the implementation. One example occurs in the CDI-TCK and it's counterpart, Arquillian. A test may want to verify that the code will result in a deployment error. Currently, to detect this exception, it's necessary to rely on an implementation specific exception class, which makes the test non-portable. Another example is a tool that starts a CDI runtime or server that provides CDI. The tool has to check for the implementation-specific exception to know if the deployment error is caused by CDI (and to capture and report that error). It important both when CDI is used for standalone bootstrap and for a container that provides CDI. Proposed APIs: javax.enterprise.inject.DeploymentException extends RuntimeException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2011