[
https://issues.jboss.org/browse/CDI-228?page=com.atlassian.jira.plugin.sy...
]
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