October 2012 - cdi-dev - Jboss List Archives

[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-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] 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

[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

11 years, 5 months

5
18
0 / 0

[JBoss JIRA] (CDI-239) Define Extension notification rules for shared libraries

by Mark Struberg (JIRA)

Mark Struberg created CDI-239: --------------------------------- Summary: Define Extension notification rules for shared libraries Key: CDI-239 URL: https://issues.jboss.org/browse/CDI-239 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Mark Struberg Consider an EAR file with a shared xy.JAR file in the EARs ./lib folder with an @EnterpriseApplicationScoped class X and a @RequestScoped class Y The EAR also contains 2 web applications WebAppA and WebAppB. WebAppA has ExtensionA in it's WEB-INF/classes and WebAppB has ExtensionB in it's classes both with a public void met(@Observes ProcessAnnotatedType pat) and each modifying the AnnotatedType. What should happen here? Will there be 2 Bean<T> for X and 2 for Y? (one Bean for each WebApp)? or will X and Y not trigger a ProcessAnnotatedType for the extensions defined in the webapps (but only for Extensions defined in the shared ear lib)? -- 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

2
2
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

11 years, 5 months

6
21
0 / 0

[JBoss JIRA] (CDI-268) Remove limitations in the SPI for creating beans

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-268: ----------------------------------- Summary: Remove limitations in the SPI for creating beans Key: CDI-268 URL: https://issues.jboss.org/browse/CDI-268 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.1.EDR Reporter: Jozef Hartinger Assignee: Pete Muir Fix For: 1.1 (Proposed) The CDI SPI provides an SPI that helps extension developers to build Bean implementations. An example follows: {code:JAVA} AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class); BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType); InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType); Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget); {code} This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior. However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI. A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean() On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed: *1.) InjectionPoint.getBean() always returns null* InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean. This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata). There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance: {code:JAVA} void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) { final InjectionPoint delegate = event.getInjectionPoint(); if (delegate.getBean() == null) { event.setInjectionPoint(new ForwardingInjectionPoint() { @Override public Bean<?> getBean() { return bean; } @Override protected InjectionPoint delegate() { return delegate; } }); } } {code} *2.) Decorators cannot be applied* Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not. To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice. -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] (CDI-283) Remove ProcessModule

by Pete Muir (JIRA)

Pete Muir created CDI-283: ----------------------------- Summary: Remove ProcessModule Key: CDI-283 URL: https://issues.jboss.org/browse/CDI-283 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.1.EDR Reporter: Pete Muir Fix For: 1.1.PRD -- 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, 6 months

1
2
0 / 0

[JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform

by Hong Zhang (JIRA)

Hong Zhang created CDI-279: ------------------------------ Summary: Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform Key: CDI-279 URL: https://issues.jboss.org/browse/CDI-279 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Hong Zhang Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform. Also attaching the relevant sections from Bill's @Stereotype proposal below: ================================================ Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI. Many existing implementations would need to be changed to understand how to expand stereotypes. Requiring every technology to do this itself will almost certainly lead to inconsistencies. Since stereotypes are a CDI feature, CDI will provide a simple replacement for the java.lang.reflect methods such as getAnnotations that takes into account stereotypes. Some technologies will not want to have a hard dependency on CDI so we'll need to provide a simple way for them to conditionally invoke these new methods only if CDI is present, falling back to java.lang.reflect if not. This seems straightforward. In this case, the functionality of @Stereotype would not be available to applications that chose to run without CDI. =============================== -- 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, 6 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2012