May 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-129) introduce @EnterpriseScoped (or similar)

by Mark Struberg (JIRA)

introduce @EnterpriseScoped (or similar) ---------------------------------------- Key: CDI-129 URL: https://issues.jboss.org/browse/CDI-129 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 1.0 Reporter: Mark Struberg Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file). There is currently no specified CDI scope for providing a single shared instance for a whole EAR. We could (ab-)use @Singleton for that, but this is currently not well defined at all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

9
144
0 / 0

[JBoss JIRA] Created: (CDI-132) Clarify which initial info AnnotatedType should contain

by Mark Struberg (JIRA)

Clarify which initial info AnnotatedType should contain ------------------------------------------------------- Key: CDI-132 URL: https://issues.jboss.org/browse/CDI-132 Project: CDI Specification Issues Issue Type: Clarification Reporter: Mark Struberg The spec is not exactly clear about the initial content of AnnotatedType. When initially building the AnnotatedType (e.g. before handing it over to the Extensions) we need to pre-fill them with the info from the annotations from the classes. Should this AnnotatedType: 1.) contain no annotations from superclasses? 2.) contain all annotations from superclasses? 3.) contain @Inherited annotations from superclasses? I think the other questions already got cleared up in CDI-70: Should AnnotatedType contain derived public? protected? private? methods/fields from a superclass? Imo it should contain all information which would be available by manually parsing any annotations. In other words: it should be possible to completely modify or emulate annotations of a parsed type. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

8
26
0 / 0

[JBoss JIRA] Created: (CDI-123) Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification

by Richard Hightower (JIRA)

Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification ----------------------------------------------------------------------------------------------------------------------------- Key: CDI-123 URL: https://issues.jboss.org/browse/CDI-123 Project: CDI Specification Issues Issue Type: Feature Request Components: Concepts Affects Versions: 1.1 (Proposed) Reporter: Richard Hightower Fix For: 1.1 (Proposed) Using Seam's CDI XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification. Annotations and Alternatives should always be the first line of offense for doing injection, decoration and interception. However, there are times when you want to configure things that don't fit well into this model. This is also useful for testing. This is not to give up type safeness via annotations, but to have some additional flexibility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

8
12
0 / 0

[JBoss JIRA] Created: (CDI-120) Add an optional Portlet specification support

by Mark Struberg (JIRA)

Add an optional Portlet specification support --------------------------------------------- Key: CDI-120 URL: https://issues.jboss.org/browse/CDI-120 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Reporter: Mark Struberg We should mention the portlet specification and how CDI-1.1 should be utilised/supported in a portlet environment. This is an important prerequisite for the JSR-344 EG to deprecate the JSF @javax.faces.bean.ManagedBean capabilities. Imo there is currently no argument which prevents to run a CDI container from running in a portlet environment anyway. No CDI interface imports any javax.servlet.* class. It could affect the wording in 6.5.2. which defines the built in scopes as being 'as defined in the Servlet specification'. We could easily extend this to also cover the portlet definition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
8
0 / 0

[JBoss JIRA] Created: (CDI-127) Add support for annotation scanning of Java enums

by Brian Leathem (JIRA)

Add support for annotation scanning of Java enums ------------------------------------------------- Key: CDI-127 URL: https://issues.jboss.org/browse/CDI-127 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Brian Leathem It would be useful if Java enums were included in the CDI annotation scan. A use case for this is found in the Seam Faces project, where we would like to use annotations on enums for configuration purposes. The annotation would look like: @ViewConfig public enum Pages { ... } It is my understanding that the current CDI specification (1.0) does not require scanning of the enum and will not pick up the @ViewConfig annotation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
12
0 / 0

[JBoss JIRA] Created: (CDI-124) Clarify how the ObserverMethod interface should be used

by Jozef Hartinger (JIRA)

Clarify how the ObserverMethod interface should be used ------------------------------------------------------- Key: CDI-124 URL: https://issues.jboss.org/browse/CDI-124 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: TBD The CDI specification (10.5) says: "For a custom implementation of the ObserverMethod interface defined in Section 11.1.3, "The ObserverMethod interface", the container must call getReception() and getTransactionPhase() to determine if the observer method is a conditional or transactional observer method, and notify() to invoke the method." However, calling ObserverMethod.getReception() is useless. An ObserverMethod implementation can be registered by an portable extension via the AfterBeanDiscovery event. The observer method may or may not be hosted by a CDI bean: a) A portable extension adds a different way of declaring an observer method on a CDI bean (e.g. using a different annotation like @Listens, or allowing a different method signature) b) A portable extension allows CDI observer methods to be registered on non-CDI beans (e.g. on a Spring Bean) In both cases, the container is not able find out if an instance of the hosting component has been created already - it does not know the hosting bean in (a) and it obviously does not know anything about the Spring bean (b). Therefore, if the observer method is conditional (ObserverMethod.getReception() returns IF_EXISTS), the container cannot decide whether it should invoke the observer method since it has no way of finding out whether the underlying instance exists or not. As a result, the container has to invoke ObserverMethod.notify() anyway. That's why I consider ObserverMethod.getReception() useless. To fix the problem, I think that the responsibility of deciding whether to invoke a conditional observer method should be shifted from container to the ObserverMethod implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-110) Allow proxying of abstract classes (Service Handler)

by George Gastaldi (JIRA)

Allow proxying of abstract classes (Service Handler) ---------------------------------------------------- Key: CDI-110 URL: https://issues.jboss.org/browse/CDI-110 Project: CDI Specification Issues Issue Type: Feature Request Components: Inheritance and Specialization Affects Versions: 1.1 (Proposed) Reporter: George Gastaldi According to mojavelinux: {quote} <mojavelinux> service handler, interceptors and decorators are all complementary <mojavelinux> and cdi is missing the first...which we now realize {quote} CDI 1.1 should provide a way to inject abstract classes by specifying a ServiceHandler (Check http://docs.jboss.org/seam/3/solder/latest/reference/en-US/html/serviceha...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

10
34
0 / 0

[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

12 years, 3 months

1
4
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

12 years, 3 months

10
18
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

12 years, 4 months

4
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2011