October 2012 - cdi-dev - Jboss List Archives

[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, 1 month

5
18
0 / 0

[JBoss JIRA] (CDI-284) Clarify AlterableContext corner cases

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-284: ----------------------------------- Summary: Clarify AlterableContext corner cases Key: CDI-284 URL: https://issues.jboss.org/browse/CDI-284 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts, Resolution Affects Versions: 1.1.PRD Reporter: Jozef Hartinger Assignee: Pete Muir Fix For: 1.1 (Proposed) There are some corner cases that are not well specified and should be improved: h3. Dependent scope The context for the @Dependent scope (DependentContext hereafter) is required to implement the AlterableContext interface. However, it is not possible to properly execute the DependentContext.destroy() method since the CreationalContext is not known. h3. Context not active The Javadoc for AlterableContext should say that the methods throws ContextNotActiveException if the method is invoked on a Context that is not active. h3. reflect CDI-24 The spec should require the container to use a serializable Contextual not only for Context.get() methods but also for AlterableContext.destroy() https://issues.jboss.org/browse/CDI-24 h3. Illegal arguments I am wondering whether the spec should be more strict and require better validation of AlterableContext.destroy() and Instance.destroy() parameters. For example: {code:JAVA} instance.destroy(new Object()); {code} should probably be considered an illegal argument. That would at least be expected by users I guess. On the other hand, such validation would disallow certain optimizations that a container may currently do (e.g. keeping only those references to dependent objects that require cleanup on destruction) -- 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 month

2
4
0 / 0

[JBoss JIRA] (CDI-275) clarify behavior of stateful beans (EJB) and cdi scopes

by Romain Manni-Bucau (JIRA)

Romain Manni-Bucau created CDI-275: -------------------------------------- Summary: clarify behavior of stateful beans (EJB) and cdi scopes Key: CDI-275 URL: https://issues.jboss.org/browse/CDI-275 Project: CDI Specification Issues Issue Type: Clarification Reporter: Romain Manni-Bucau EJB specification let think the Stateful beans should be user managed so what about the integration with CDI and in particular the @Remoe methods I think it is not so clear in the current specification and that @requestScoped (or session...) on a statful bean should be clarified -- 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 month

3
8
0 / 0

[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation

by Mark Struberg (JIRA)

Mark Struberg created CDI-274: --------------------------------- Summary: BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation Key: CDI-274 URL: https://issues.jboss.org/browse/CDI-274 Project: CDI Specification Issues Issue Type: Bug Components: Beans Affects Versions: 1.1.EDR Reporter: Mark Struberg We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in a @Observes ProcessBean method. Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs. PROPOSAL: We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error. -- 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 month

2
6
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-272) Decorating built-in beans - move the exception for BeanManager to more appropriate chapter

by Martin Kouba (JIRA)

Martin Kouba created CDI-272: -------------------------------- Summary: Decorating built-in beans - move the exception for BeanManager to more appropriate chapter Key: CDI-272 URL: https://issues.jboss.org/browse/CDI-272 Project: CDI Specification Issues Issue Type: Clarification Components: Decorators Reporter: Martin Kouba Move the sentence _"Any decorators associated with BeanManager will not be applied"_ from *11.5. Container lifecycle events* to *8. Decorators* or *11.3. The BeanManager object*. Being placed in 11.5. does not cover the exception for runtime use. -- 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 month

2
3
0 / 0

[JBoss JIRA] (CDI-287) Clarify the order of CDI interceptors wrt. around-invoke method of target class

by Ron Šmeral (JIRA)

Ron Šmeral created CDI-287: ------------------------------ Summary: Clarify the order of CDI interceptors wrt. around-invoke method of target class Key: CDI-287 URL: https://issues.jboss.org/browse/CDI-287 Project: CDI Specification Issues Issue Type: Clarification Components: Interceptors Affects Versions: 1.0 Reporter: Ron Šmeral Currently, the CDI specification doesn't define, when is the around-invoke method of a target class called, with regard to CDI interceptors. The spec. only says, in 9.4, towards the end: bq. Interceptors declared using {{@Interceptors}} or in {{ejb-jar.xml}} are called before interceptors declared using interceptor bindings. Currently, the order happens to be (in EAP6): # {{@Interceptors}} and {{ejb-jar.xml}} # Around-invoke method # CDI interceptors In the following example the order of interception would be: # {{FirstInterceptor}} # {{SomeClass.aroundInvoke}} # {{ThirdInterceptor}} \\ \\ {code} public class SomeClass { @ThirdInterceptorBinding // bound to ThirdInterceptor @Interceptors(FirstInterceptor.class) public int doSomething() { // ... } @AroundInvoke // comes second public Object aroundInvoke(InvocationContext invocationContext) throws Exception { return invocationContext.proceed(); } } {code} This problem manifests in this (currently skipped) test: https://github.com/weld/core/blob/1.1/tests-arquillian/src/test/java/org/... -- 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 month

4
7
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-256) CDI spec is not consistent in treating types selected by Event

by Pete Muir (JIRA)

Pete Muir created CDI-256: ----------------------------- Summary: CDI spec is not consistent in treating types selected by Event Key: CDI-256 URL: https://issues.jboss.org/browse/CDI-256 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) 10.3.1 says "The Event interface provides a method for firing events with a specified combination of type and qualifiers:" but then goes on to ignore the type later on "The method fire() fires an event with the specified qualifiers and notifies observers, as defined by Section 10.5, “Observer notification”." -- 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 month

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2012