October 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-267) Consider annotating built in scopes with @Scope

by Julien Viet (JIRA)

Julien Viet created CDI-267: ------------------------------- Summary: Consider annotating built in scopes with @Scope Key: CDI-267 URL: https://issues.jboss.org/browse/CDI-267 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Julien Viet The @Inject spec defines the @Singleton annotation that can be used in @Inject impls or CDI . The annotations defined in CDI can only be used in CDI and could not be reused with @Inject impl. It technically (or per the spec) it is possible to annotation the CDI annotations with @Scope (in addition of @NormalScope) then those annotations could be reused in @Inject implemetentation, removing the need for proprietary annotations that do the same (com.google.inject.servlet.RequestScoped for example). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
6
0 / 0

[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method

by Arne Limburg (JIRA)

Arne Limburg created CDI-271: -------------------------------- Summary: Provide a way to inject Event metadata into an observer method Key: CDI-271 URL: https://issues.jboss.org/browse/CDI-271 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Reporter: Arne Limburg Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members). Consider the following example: {code} @Inject @MyQualifier Event<MyObject> event; public void fireEvent(MyObject object, MyTypeValue type) { event.select(new MyTypeAnnotationLiteral(type)).fire(object); } {code} Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this: {code} public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) { MyType annotation = ip.getAnnotated().getAnnotation(MyType.class); MyTypeValue value = annotation.value(); ... } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
12
0 / 0

[JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events

by Pete Muir (JIRA)

Pete Muir created CDI-270: ----------------------------- Summary: Allow @WithAnnotations to be applied to other events Key: CDI-270 URL: https://issues.jboss.org/browse/CDI-270 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.EDR Reporter: Pete Muir Fix For: 1.1 (Proposed) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
2
0 / 0

[JBoss JIRA] (CDI-226) Clarify the @Singleton behaviour

by Daniel Sachse (JIRA)

Daniel Sachse created CDI-226: --------------------------------- Summary: Clarify the @Singleton behaviour Key: CDI-226 URL: https://issues.jboss.org/browse/CDI-226 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts Affects Versions: 1.1.EDR1 Reporter: Daniel Sachse The specification should make a more clear statement about the Scope and Lifecycle of the @Singleton annotation. ATM it is e.g. totally unclear, in which environment a Singleton is guaranteed to be a Singleton(JVM, EAR, WAR,... ). -- 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

3
4
0 / 0

[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] (CDI-233) Specify target bean archive for bean added via AfterBeanDiscovery.addBean()

by Martin Kouba (JIRA)

Martin Kouba created CDI-233: -------------------------------- Summary: Specify target bean archive for bean added via AfterBeanDiscovery.addBean() Key: CDI-233 URL: https://issues.jboss.org/browse/CDI-233 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba This may have impact, provided that alternatives, interceptors or decorators are used. -- 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

3
10
0 / 0

[JBoss JIRA] (CDI-200) ProcessBeanAttributes needs clarification

by Jozef Hartinger (Created) (JIRA)

ProcessBeanAttributes needs clarification ----------------------------------------- Key: CDI-200 URL: https://issues.jboss.org/browse/CDI-200 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) The specification should clarify the following cases: * whether the ProcessBeanAttributes event should be fired for Beans registered using AfterBeanDiscovery.addBean() - if yes, it is necessary to clarify what would the value returned by PBA.getAnnotated() be. * whether the ProcessBeanAttributes event should be fired for built-in beans (my interpretation is that this is not required) The attributes represented by a BeanAttributes object are not completely independent. It is necessary to clarify how the set BeanAttributes object is treated. I can see two options: * the container takes the final values of a BeanAttributes object and uses them * the container itself updates certain attributes to match CDI rules for example ** if an extension adds a @Named qualifier to the set of qualifiers, this change is automatically reflected within the name attribute ** if an extension adds a stereotype, which is (transitively) annotated with @Named, the default name is implied and reflected within the name attribute ** if an extension adds a stereotype, which is (transitively) annotated with @Alternative, this fact is reflected within the isAlternative attribute ** if an extension adds a stereotype, which is (transitively) annotated with a scope annotation, this fact is reflected within the scope attribute In theory, conflicts may occur where for example an extension may set different values for the @Named qualifier and for the name attribute. With the latter approach, an extension loses part of the control. On the other hand, this approach may be more convenient. Another area that needs clarification is specialization. Suppose having beans A and B where B specializes A. According to the specification, the result of specialization should be visible at the time the ProcessBeanAttributes event is fired for B (the qualifiers and name of B are updated with values of A). The scenarios that need clarification are: * In the ProcessBeanAttributes phase, a qualifier is added to A (making B no longer a valid substite of A). Should the container detect this as a definition error or rather apply specialization (update the set of qualifiers of B) once again? The same applies for name. * Similarly, the set of qualifiers of B may be reduced by an extension, causing the same problem. -- 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

2
5
0 / 0

[JBoss JIRA] (CDI-281) ObserverMethod.notify() breaks backwards compatibility

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-281: ----------------------------------- Summary: ObserverMethod.notify() breaks backwards compatibility Key: CDI-281 URL: https://issues.jboss.org/browse/CDI-281 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 1.1.EDR Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.1 (Proposed) ObserverMethod.notify(T event, Set<Annotation> qualifiers) has been added post CDI 1.0 as part of CDI-36. The added method breaks backwards compatibility (an existing 1.0 Extension may be registering an ObserverMethod implementation that would not implement that method, since it is not part of the 1.0 API). We should probably isolate that method into a subinterface e.g.: {code:JAVA} public interface CuriousObserverMethod<T> extends ObservetMethod<T> { void notify(T event, Set<Annotation> qualifiers); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
4
0 / 0

[JBoss JIRA] (CDI-286) Inconsistencies in chapter "Validation of passivation capable beans and dependencies"

by Martin Kouba (JIRA)

Martin Kouba created CDI-286: -------------------------------- Summary: Inconsistencies in chapter "Validation of passivation capable beans and dependencies" Key: CDI-286 URL: https://issues.jboss.org/browse/CDI-286 Project: CDI Specification Issues Issue Type: Bug Reporter: Martin Kouba The spec states in 6.6.4. "Validation of passivation capable beans and dependencies": {quote} If a bean which declares a passivating scope type, or any stateful session bean, has a decorator or interceptor which is not a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem. {quote} WRT CDI-136 "If a bean which declares a passivating scope type, or any stateful session bean," should be replaced with: "If a managed bean or stateful session bean which declares a passivating scope". I'm not sure about the wording _"has a decorator or interceptor which is not a passivation capable dependency"_ because the wording in section 6.6.1. "Passivation capable beans" is _"interceptors and decorators of the bean are passivation capable"_ (passivation capable dependency vs passivation capable). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
7
0 / 0

[JBoss JIRA] (CDI-282) Vetoing types - clarify consequences

by Martin Kouba (JIRA)

Martin Kouba created CDI-282: -------------------------------- Summary: Vetoing types - clarify consequences Key: CDI-282 URL: https://issues.jboss.org/browse/CDI-282 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba The spec currently says {{@Vetoed}} type is *prevented from being considered by CDI* and {{ProcessAnnotatedType.veto()}} forces the container to ignore the type. This is quite obvious for classes and interfaces. However not so clear when vetoing annotations (e.g. qualifier). I think ignoring means not being considered as qualifier (thus affects resolution). Other (rather theoretical) example is vetoing non-contextual instances - should it prevent performing dependency injection? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2012