[ 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. -- This message was sent by Atlassian JIRA (v7.5.0#75005)