[cdi-dev] [JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits

[Arne Limburg (JIRA)]

    [ https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754334#comment-12754334 ] 

Arne Limburg commented on CDI-228:
----------------------------------

Personally I think that @DestroyedAfterBlock is not readable and most time misleading.

Most time this feature is needed, is to circumvent the passivation capable check, that means to mark a parameter just being used to create the result of the method and not held by the result.

I.e. I had the case where I wanted to produce a passivation capable bean created from some request parameters. So I injected the FacesContext (which is not serializable). This wasn't possible due to the passivation-capable restriction. With CDI 1.1 I would annotate that parameter. But the annotation @DestroyedAfterBlock is misleading here, because I don't want the FacesContext to be destroyed after the call to the producer method (and in fact it will not, because I don't have a disposer method in my FacesContextProducer).
This code really looks wrong:

{code}
@Produces
public String getRequestParameterValue(@DestroyedAfterBlock FacesContext facesContext) {
  return facesContext.getExternalContext().getRequestParameterMap().get("myName");
}
{code}
                
> 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.EDR
>            Reporter: Mark Struberg
>            Assignee: Pete Muir
>            Priority: Critical
>             Fix For: 1.1.PFD
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira