September 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-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] (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] 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-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits

by Mark Struberg (JIRA)

Mark Struberg created CDI-228: --------------------------------- Summary: Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits Key: CDI-228 URL: https://issues.jboss.org/browse/CDI-228 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts Affects Versions: 1.1.EDR1 Reporter: Mark Struberg This clarification is intended for all methods which gets invoked by the CDI container and create a new @Dependent contextual instance especially for this invocation. This can happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject contructors. Basically any @Dependent method-parameter InjectionPoint. Despite it's atm not specified whether this @Dependent instance will get stored, most containers store it in the CreationalContext of the bean containing the invoked method. This behaviour can lead to mem leaks and non-serializibility issues. TASK: Define that any @Dependent contextual instance will get properly destroyed after such method invocations. There are 2 things we need to think about: 1.) any @PreDestroy method of those beans will get invoked after the method invocation, even if the @Dependent instance will stored away in a member field and still being used later. This will not make any problems in most cases. We just need to make people aware that this will happen. 2.) As any Decorator or Interceptor is also an @Dependent instance on our 'temporary' created @Dependent method parameter, those Interceptors and Decorators will _not_ be available after the method invocation. Storing away this bean and re-using it later will probably cause an Exception. I still think this is a small problem compared to creating tons of mem leaks. There are quite a few workarounds possible: *) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize it. *) We might add an additional annotation which denotes either @Transactional or au contraire: @Keep for the method-param InjectionPoint -- 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

5
18
0 / 0

[JBoss JIRA] Created: (CDI-164) Decorating built in beans

by Jozef Hartinger (JIRA)

Decorating built in beans ------------------------- Key: CDI-164 URL: https://issues.jboss.org/browse/CDI-164 Project: CDI Specification Issues Issue Type: Feature Request Components: Decorators Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) In CDI 1.0, decorators may only be applied to managed and session beans. Decorating built-in beans would make CDI extensions more powerful. One of the possible usecases is represented by decorating the Event bean https://gist.github.com/1223042 This would allow extensions to implement for example: * event queuing (Forge) * bidirectional mapping to another event technology without introducing infinite loops (Seam JMS) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
15
0 / 0

[JBoss JIRA] (CDI-205) Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations

by Martin Kouba (Created) (JIRA)

Invocations of message listener methods of message-driven beans during message delivery should not be business method invocations --------------------------------------------------------------------------------------------------------------------------------- Key: CDI-205 URL: https://issues.jboss.org/browse/CDI-205 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.EDR1, 1.0 Reporter: Martin Kouba Priority: Critical *7.2. Container invocations and interception* states: When the container invokes a method of a bean, the invocation may or may not be treated as a business method invocation: * Invocations of message listener methods of message-driven beans during message delivery are business method invocations. As MDBs are not CDI beans their methods shouldn't be business invocations (and thus should not pass through method interceptors and decorators). If the original intent was to support such use case the spec should be reworded. -- 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, 1 month

6
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012