March 2012 - 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] (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] 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

[JBoss JIRA] (CDI-214) Remove the need to store the BeanManager in the Servlet attributes

by Mark Struberg (JIRA)

Mark Struberg created CDI-214: --------------------------------- Summary: Remove the need to store the BeanManager in the Servlet attributes Key: CDI-214 URL: https://issues.jboss.org/browse/CDI-214 Project: CDI Specification Issues Issue Type: Bug Components: Concepts Affects Versions: 1.1.EDR1 Reporter: Mark Struberg Fix For: 1.1 (Proposed) the CDI-1.1-EDR1 added a new feature (CDI-14): > spi.xml- <para>Web components may obtain an instance of <literal>BeanManager</literal> > spi.xml: by calling <literal>ServletContext.getAttribute("javax.enterprise.inject.spi.BeanManager")</literal>. Imo we should remove this again and instead propose the usage of the new CDI.current() for such situations. -- 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

2
9
0 / 0

[JBoss JIRA] Created: (CDI-162) Support Extended Persistence Contexts in Managed beans

by Pete Muir (JIRA)

Support Extended Persistence Contexts in Managed beans ------------------------------------------------------ Key: CDI-162 URL: https://issues.jboss.org/browse/CDI-162 Project: CDI Specification Issues Issue Type: Tracker Reporter: Pete Muir -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

5
22
0 / 0

[JBoss JIRA] (CDI-206) Conversation related exceptions cannot be handled

by Jozef Hartinger (Created) (JIRA)

Conversation related exceptions cannot be handled ------------------------------------------------- Key: CDI-206 URL: https://issues.jboss.org/browse/CDI-206 Project: CDI Specification Issues Issue Type: Bug Components: Contexts Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) This issue emerged after adding support for conversations as part of CDI-80 The spec says: {quote}The conversation associated with a Servlet request is determined at the beginning of the request before calling any service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web application and before the container calls any ServletRequestListener or AsyncListener in the web application. {quote} and {quote} If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException. The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.BusyConversationException. {quote} The conversation association is supposed to be done before any servlet, filter or listener is invoked. If the association fails (due to NonexistentConversationException or BusyConversationException), the application has no way of handling this failure gracefully. The Servlet error-page mechanism cannot be used portably because it is only handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used exception handling mechanism - an outer filter that catches every uncaught exception, cannot be used since the association failure does not occur within the filter invocation. -- 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

5
9
0 / 0

[JBoss JIRA] Created: (CDI-139) Support for unmanaged instances

by Joshua Davis (JIRA)

Support for unmanaged instances ------------------------------- Key: CDI-139 URL: https://issues.jboss.org/browse/CDI-139 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 1.0 Reporter: Joshua Davis Allow the creation of unmanaged instances. The CDI context will not keep track of these instances and the application will be responsible for cleaning them up. This is a fairly typical usage of other DI frameworks such as Guice and PicoContainer. Currently, if an ApplicationScoped object injects an {{Instance<T>}} interface, CDI will manage all instances returned by the {{get()}} method as dependents of the application scoped object. Those instances will be kept in memory by the CDI implementation and will only be GC'd when the application scoped object is destroyed (at the end of the application). This may look like a memory leak to the user (see WELD-920). >From P. Muir on WELD-920 {quote} We can describe instances which are attached (as the CDI 1.0 spec requires) as "managed" instances, and those which the user takes responsibility for cleaning up themselves as "unmanaged" instances. In CDI 1.1 I would like to add support for unmanaged instances (the impl will just hand these over and forget about them) and also to allow the app to request an unmanaged instance is cleaned up. Please can someone file a CDI issue for this? Weld could certainly be more friendly and more proactively discard instances. Ideas: 1) Analyse the dependent instance graph, and if there are no @PreDestroy/@Disposer callbacks on in the graph, do not store the dependent instance for cleanup (this would be a good general optimization (2) Add a config option to allow instances created from Instance to be held only as long as the app holds a reference, and if the app doesn't hold a reference for it's lifetime, then Weld would not do any cleanup (Weld would hold a weak ref). {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
18
0 / 0

[JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

by Jozef Hartinger (Created) (JIRA)

Allow AnnotatedType for a given Bean to be obtained --------------------------------------------------- Key: CDI-194 URL: https://issues.jboss.org/browse/CDI-194 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) See Stuart's comment on CDI-83. -- 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

5
18
0 / 0

[JBoss JIRA] (CDI-218) Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes a bean archive

by Dan Allen (JIRA)

Dan Allen created CDI-218: ----------------------------- Summary: Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes a bean archive Key: CDI-218 URL: https://issues.jboss.org/browse/CDI-218 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Reporter: Dan Allen Priority: Minor Chapter 12.1 specifies that beans.xml must be in the WEB-INF directory of a web archive to activate the WEB-INF/classes directory of that war as a bean archive (and thus make java:comp/BeanManager visible to the web app). However, many developers find this location both confusing and inconvenient at times. The instinct of many developers is to put the beans.xml in WEB-INF/classes/META-INF since that follows the convention that applies to library jars. Obviously, we cannot break backwards compatibility. Therefore, this issue proposes to honor either location in the war: - WEB-INF/beans.xml - WEB-INF/classes/META-INF/beans.xml If both files are present, the WEB-INF/beans.xml should take precedence and a warning is recommended. (Merging them is not likely the behavior that a developer would want). -- 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
21
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2012