[cdi-dev] [JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls

Matej Novotny (JIRA) issues at jboss.org
Tue Jul 3 03:19:00 EDT 2018


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

Matej Novotny commented on CDI-732:
-----------------------------------

bq. A session only makes sense if there is a request...

One or more requests exist/live within a session. It seems logical to first destroy the "shorter-lived" scopes such as request and conversation and only after that the "encompassing" session.

bq. Also specifications made request scope available almost everywhere...

True but in many cases it is artificial in a sense that new beans are created for just that occasion and then tossed away. That could be done even here, but the usefulness is arguable - I would expect to either have that bean existing with a given state (in case of invalidation) or to not have it at all.

> Clarify that the Context for RequestScoped must be active during @PreDestroy calls
> ----------------------------------------------------------------------------------
>
>                 Key: CDI-732
>                 URL: https://issues.jboss.org/browse/CDI-732
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts
>    Affects Versions: 2.0 .Final
>            Reporter: Mark Struberg
>
> We have the explicit rule that the Context for @RequestScoped must be active during @PostConstruct of any bean. 
> But it seems we don't force the same for invocations of @PreDestroy methods.
> That's especially weird since a few containers now blow up during a destroyal of a @SessionScopedBean which has a @RequestScoped Principal injected, even if the session destroyal was triggered by an explicit Session#invalidate() call in an open HTTP request.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


More information about the cdi-dev mailing list