[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:
----------------------------------------
[~manovotn] at the end it is exactly the same. You can see session scope or conversation scope as being dependent on the request so it must be destroyed before when they are destroyed during a request.
> 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:
-----------------------------------
bq. conversation is clearly longer than request. Thus this argument makes no sense.
Clearly not so much when it is transient, so it makes sense. The lifespan of a conversation can differ and there is no "perfect fit" for it.
> 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-587) Propose a way to propagate an existing context
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau edited comment on CDI-587 at 7/18/18 9:43 AM:
-----------------------------------------------------------------
Since CDI 2 we could have a simple solution reusing RequestContextController and adding a method to be able to manipulate the context:
{code}
RequestContextController scope = controller.handler();
// do something
// start a new thread or eq () -> {
scope.activate();
try { /*...*/}
finally { scope.deactivate(); }
// };
{code}
It would:
1. let to the caller the thread safety responsability
2. use some kind of reference counting to not destroy the scope too early (before all deactivate are called)
was (Author: rmannibucau):
Since CDI 2 we could have a simple solution reusing RequestContextController and adding a method to be able to manipulate the context:
{code}
RequestContextController scope = controller.handler();
// do something
// start a new thread or eq () -> {
scope.activate();
try { /*...*/}
finally { scope.deactivate(); }
// };
It would:
1. let to the caller the thread safety responsability
2. use some kind of reference counting to not destroy the scope too early (before all deactivate are called)
> 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-587) Propose a way to propagate an existing context
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-587:
----------------------------------------
Since CDI 2 we could have a simple solution reusing RequestContextController and adding a method to be able to manipulate the context:
{code}
RequestContextController scope = controller.handler();
// do something
// start a new thread or eq () -> {
scope.activate();
try { /*...*/}
finally { scope.deactivate(); }
// };
It would:
1. let to the caller the thread safety responsability
2. use some kind of reference counting to not destroy the scope too early (before all deactivate are called)
> 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-587) Propose a way to propagate an existing context
by Gordon Hutchison (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:43 AM:
---------------------------------------------------------------
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with a 'real' request,
3 - or a null context (exception if scoped bean injected) or...
4 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed i.e. when the Publisher calls onNext on the Subscribers etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
was (Author: hutchig):
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with a 'real' request,
3 - or a null context (exception if scoped bean injected) or...
4 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
> 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-587) Propose a way to propagate an existing context
by Gordon Hutchison (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:42 AM:
---------------------------------------------------------------
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with a 'real' request,
3 - or a null context (exception if scoped bean injected) or...
4 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
was (Author: hutchig):
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request,
3 - or a null context (exception if scoped bean injected) or...
4 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
> 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-587) Propose a way to propagate an existing context
by Gordon Hutchison (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:40 AM:
---------------------------------------------------------------
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request,
3 - or a null context (exception if scoped bean injected) or...
4 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
was (Author: hutchig):
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request,
3 - or a null context (exception if scoped bean injected) or...
3 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
> 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-587) Propose a way to propagate an existing context
by Gordon Hutchison (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Gordon Hutchison edited comment on CDI-587 at 7/18/18 9:37 AM:
---------------------------------------------------------------
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request,
3 - or a null context (exception if scoped bean injected) or...
3 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
was (Author: hutchig):
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request,
3 - or a null context (exception if scoped bean injected) or...
3 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
> 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-587) Propose a way to propagate an existing context
by Gordon Hutchison (JIRA)
[ https://issues.jboss.org/browse/CDI-587?page=com.atlassian.jira.plugin.sy... ]
Gordon Hutchison commented on CDI-587:
--------------------------------------
The issue of the lifecyle of the RequestScope is touched on in the discussion thread.
For a reactive stream, one can envisage that for a linear graph of publisher;[processor*];subscriber one could have a simple mental model of propogating contexts.
However one could also envisage an operator, for example, that passed on the maximum of every 10 stream elements
- downstream of this, which of the 10 incoming contexts should be propogated? One could envisage:
1 - provide an API - enabling the Publisher(/Operator) to
select the downstream context as a function of the contexts associated with the onNext items passed in,
2 - a new context (enabling @RequestScoped beans to be used but not shared with the 'real request,
3 - or a null context (exception if scoped bean injected) or...
3 - one could specify it was the context that was
active when the 'last' of each ten stream elements was processed etc.
What, for example, would be the correct RequestScope downstream of CombineLatest operator
if each operand stream had a valid RequestScope? How would the CombineLatest operator function
'help' the system provide the correct RequestScope downstream?
https://channel9.msdn.com/Blogs/J.Van.Gogh/Reactive-Extensions-API-in-dep...
A similar situation could be set up using CompletionStage:runAfterBothAsync etc.
> 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
