[JBoss JIRA] (CDI-587) Propose a way to propagate an existing context
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-587:
---------------------------------
I vote for this issue. I also would like to see the contexts for SessionScoped, ConversationScoped are also propagated. I came up with the similar design as Romain. The default should be 'false' for context propagation so that the existing apps remain unaffected.
> Propose a way to propagate an existing context
> ----------------------------------------------
>
> Key: CDI-587
> URL: https://issues.jboss.org/browse/CDI-587
> Project: CDI Specification Issues
> Issue Type: Epic
> Components: Contexts
> Affects Versions: 1.2.Final
> Reporter: Romain Manni-Bucau
>
> The overall idea is to ensure that it is not cause the code becomes asynchronous/reactive/... that we loose the instances or get another context.
> An example is starting an AsyncContext in a servlet.
> One proposal is to add a flag to ask for propagation of the context in async managed threads: @RequestScoped(inherited = true) which would reuse the same instances for these "new" threads.
> Note however this issue is not only bound to servlets even if it is the easiest example.
> The original thread disucssion on the list: http://cdi-development-mailing-list.1064426.n5.nabble.com/RequestScope-Li...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-732:
-----------------------------------
The problem is that lots of code relies on the RequestScoped context. E.g. if you use a @RequestScoped Principal. Or a @RequestScoped EntityManager. In the first case you might get a default user and yes, this might be hard to understand for the user. I would also prefer to end the Session before the Request Context.
> 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)
6 years, 5 months
[JBoss JIRA] (CDI-730) The order in which contexts are destroyed is undefined.
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-730?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-730:
-----------------------------------
I understand the argument that the order is really hard to get right.
But I would love if we could clarify the following:
* When a request ends, first ALL the @BeforeDestroyed events for the following contexts are sent: RequestScope, ConversationScoped (if context ends), SessionScoped (if session ends)
* Only after that the proper @PreDestroy methods are called on all those scopes.
PS: the deferral of the session destroy to the end of the request is a left over of the (failed) Seam2 compatibility mode. It should have never be done that way and really causes tons of problems :(
In OWB there is even a way to turn this off and make it follow the standard Servlets Sesion lifecycle because it caused so many problems.
> The order in which contexts are destroyed is undefined.
> -------------------------------------------------------
>
> Key: CDI-730
> URL: https://issues.jboss.org/browse/CDI-730
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.Future, 1.2.Final, 2.0 .Final
> Reporter: Benjamin Confino
> Priority: Minor
>
> The order in which contexts are destroyed is not defined in the spec, I believe this should be made explicit.
> At present weld destroys conversation, request, then session context in that order. I think this should become the standard and written into the spec.
> For background there is this email by Martin Kouba: http://lists.jboss.org/pipermail/weld-dev/2018-June/003694.html
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-732:
----------------------------------------
[~struberg] this doesn't solve the problem correctly IMHO. request = thread scope is an abuse of users but not what is the scope normally. A lot of usages are about request = ... request :). If you think about an audit implementation by request you breaks it if the request scope is not the last one destroyed so I think session should be destroyed before the request in any case. Having 2 instances in the same real servlet request would be very misleading and pretty much unusable at all stages (perf, understanding, impl).
> 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)
6 years, 5 months
[JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-732:
-----------------------------------
> It seems logical to first destroy the "shorter-lived" scopes
Hmm but Welds destroy order according to CDI-730 is
> At present weld destroys conversation, request, then session context in that order.
conversation is clearly longer than request. Thus this argument makes no sense.
Another point to think about: in CDI the RequestScoped Context is also used as kind of 'ThreadScoped'. For example it is also active in an Asynchronous EJB method, in JBatch threads, etc.
So even if the Session gets destroyed outside of a HTTP Request (e.g. via timeout), then we could start a RequestContext, perform the @PreDestroy method and stop if afterwards.
> 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)
6 years, 5 months
Portable decorable Bean<T> instances
by arjan tijms
Hi,
When adding a manually constructed Bean<T> instance using
AfterBeanDiscovery.addBean(Bean<?>), or using the
AfterBeanDiscovery.addBean() method and the BeanConfigurator, the resulting
bean can't be decorated.
This is because seemingly CDI expects the create() method of Bean<T> to
locate the decorators itself and apply them to the instance it returns.
Using BeanManager.resolveDecorators one can obtain the Decorator<T>
instances, but am I right that there's no portable way to actually apply
those decorators to the bean instance?
Kind regards,
Arjan
6 years, 5 months
[JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.sy... ]
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)
6 years, 5 months
[JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-732:
----------------------------------------
Isnt it the opposite actually? A session only makes sense if there is a request so last request must stay longer than its session (except invalidate case but this one is clear). Also specifications made request scope available almost everywhere so it would create an exception to not align it on the servlet behavior.
> 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)
6 years, 5 months
[JBoss JIRA] (CDI-732) Clarify that the Context for RequestScoped must be active during @PreDestroy calls
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-732?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-732:
-----------------------------------
I am afraid "very end" is still somewhat vague, but I do agree that it makes more sense to first destroy request scoped, then session scoped beans.
> 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)
6 years, 5 months
