November 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-299) Consider removing @Vetoed on packages

by Pete Muir (JIRA)

Pete Muir created CDI-299: ----------------------------- Summary: Consider removing @Vetoed on packages Key: CDI-299 URL: https://issues.jboss.org/browse/CDI-299 Project: CDI Specification Issues Issue Type: Bug Reporter: Pete Muir What happens when a package is split across jars? What about recursing into sub packages? -- 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

11 years, 5 months

4
11
0 / 0

[JBoss JIRA] (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-3: ----------------------------- CDI EG agree to add this > Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes > ------------------------------------------------------------------------------------------------------------ > > Key: CDI-3 > URL: https://issues.jboss.org/browse/CDI-3 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Critical > Fix For: 1.1 (Proposed) > > > At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes. > Some of the things that the bean interface will not let you mimic are: > - Interceptors > - Disposal methods > - Producer fields for normal scoped beans -- 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

11 years, 5 months

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

11 years, 5 months

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

11 years, 5 months

5
9
0 / 0

[JBoss JIRA] (CDI-291) Clarify interceptor/decorator resolution rules

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-291: ----------------------------------- Summary: Clarify interceptor/decorator resolution rules Key: CDI-291 URL: https://issues.jboss.org/browse/CDI-291 Project: CDI Specification Issues Issue Type: Clarification Components: Decorators, Interceptors Affects Versions: 1.0 Reporter: Jozef Hartinger Assignee: Pete Muir Fix For: 1.1 (Proposed) Currently the spec only says: {quote} A decorator is bound to a bean if: * The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu- tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points"). * The decorator is enabled in the bean archive containing the bean. {quote} AND {quote} An interceptor is bound to a method if: * The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which is not annotated @javax.enterprise.util.Nonbinding. * The interceptor intercepts the given kind of lifecycle callback or business method. * The interceptor is enabled in the bean archive containing the bean. {quote} What remains unspecified is: * In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from X. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application. * Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery. -- 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

11 years, 5 months

2
1
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-83: ------------------------------ Go ahead with this > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-58: ------------------------------ Go ahead with this. > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1 (Proposed) > > > This decision is really important to make. Either we remove/redefine BeanManager#getAnnoatadType(Class) or we remove the 'artificial annotated types'. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-278) Clarify scope of Stateless and Singleton EJB's

by Stuart Douglas (JIRA)

Stuart Douglas created CDI-278: ---------------------------------- Summary: Clarify scope of Stateless and Singleton EJB's Key: CDI-278 URL: https://issues.jboss.org/browse/CDI-278 Project: CDI Specification Issues Issue Type: Bug Reporter: Stuart Douglas At the moment Stateless and Singleton beans are classified as @Dependent scope by default, which is not really very useful, as a lot of the rules for dependent scoped beans simple do not apply to them (they violate pretty much every rule for dependent scoped beans in 6.4). I think we need to define a new scope for these beans, or at least clarify their behaviour when they are @Dependent scoped. -- 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

11 years, 5 months

5
13
0 / 0

[JBoss JIRA] (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-3: ----------------------------- We would still like to add this event. Any objections? > Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes > ------------------------------------------------------------------------------------------------------------ > > Key: CDI-3 > URL: https://issues.jboss.org/browse/CDI-3 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Priority: Critical > Fix For: 1.1 (Proposed) > > > At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes. > Some of the things that the bean interface will not let you mimic are: > - Interceptors > - Disposal methods > - Producer fields for normal scoped beans -- 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

11 years, 5 months

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

11 years, 5 months

6
18
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2012