[cdi-dev] [JBoss JIRA] (CDI-587) Propose a way to propagate an existing context

[Gordon Hutchison (JIRA)]

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

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-depth-CombineLatest

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-depth-CombineLatest

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-Life-Cycle-td5712701.html



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