Thank you Matej You are correct to bring up threading, this is done on a single thread - for performance reasons WebSphere keeps both ends of an RMI on a single thread for performance reasons. But I confess this feels a little unintuitive to me. The fact we do everything on one thread feels like an implementation detail. What would happen if there was a new thread for processing an RMI? Would weld try to identify the correct pre-existing request context to associate with? Or require us to do so? When drafting this reply to you I noticed this in the spec that I missed the first time: The context associated with a built-in normal scope propagates across local, synchronous Java method calls, including invocation of EJB local business methods. The context does not propagate across remote method invocations or to asynchronous processes such as JMS message listeners or EJB timer service timeouts. Please could you help me understand how that "does not propagate" fits in what you've said before. Are you saying it really does come down to the fact we're handling RMIs on the same thread as the service() method that invokes them? Regards Benjamin From: Matej Novotny <manovotn(a)redhat.com&gt; To: Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; Cc: weld-dev(a)lists.jboss.org Date: 01/06/2021 14:27 Subject: [EXTERNAL] Re: [weld-dev] Request Scope Lifecycle and Remote EJB invocations Hello, from your description and the diagram I gather that the whole thing happens inside a single service() invocation. The thing with CDI contexts is that they are thread-bound. Your context either is or isn't active on a thread. ‍‍‍‍ Hello, from your description and the diagram I gather that the whole thing happens inside a single service() invocation. The thing with CDI contexts is that they are thread-bound. Your context either is or isn't active on a thread. CDI defines several cases for which it has to be active - such as the service() invocation or the RMI - but it doesn't say anything about the context being a new one; just active, which holds true in your scenario. Therefore, what you are seeing is IMO expected behavior. While executing the sequence of actions, you are still on one thread and the original req. context (that is activated by an actual HTTP request) is supposed to live until the service() method ends. By ending it mid-way, you'd violate its lifecycle. Not to mention that it could create some weird situations if you attempted to pause/stop/restart the same context several times in one request. Also, the same logic is applied to whenever CDI spec requires some context to be active for certain action (async events, RMI, ...) - we basically check if it already is active and only in case it isn't we activate it. That's my understanding of it, hope it helps :-) Regards Matej On Tue, Jun 1, 2021 at 11:22 AM Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; wrote: Hello I have a customer who sent me a pair of applications with the following behaviour (see also the attached flow diagram): 1. A request is sent to a REST resource in Application A 2. The endpoint makes a RMI call to ServiceB in Application B 3. ServiceB makes an RMI to ServiceA in Application A 4. ServiceA makes an RMI to ServiceB in Application B 5. ServiceB calls back to the rest resource. A @RequestScoped bean is injected into the REST Resource and Service A. The customer has noticed the same instance of that bean is injected into both injection points. They believe the two should be separate request scoped contexts. The CDI spec says the request context is alive : during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any ServletRequestListener or AsyncListener, during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB timeout method and during message delivery to any EJB message-driven bean, and But it is not clear what happens if a remote method invocation is nested inside a service() method. Is that a separate request context or the same as the parent? If they are seperate contexts, I notice that WeldInitialListener.requestInitialized requires a ServletRequestEvent, which would be tricky to acquire as part of processing an EJB remote method invocation. Would I need to find a way to access a ServletRequestEvent when creating the request context for a RMI? Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ weld-dev mailing list -- weld-dev(a)lists.jboss.org To unsubscribe send an email to weld-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Thank you Matej That covers everything. Regards Benjamin From: Matej Novotny <manovotn(a)redhat.com&gt; To: Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; Cc: weld-dev(a)lists.jboss.org Date: 02/06/2021 12:40 Subject: [EXTERNAL] Re: [weld-dev] Request Scope Lifecycle and Remote EJB invocations This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd asynchronous processes. Well, this specifically says that in RMI and async processes (async events), the context does not propagate. Which is why specification then goes on to say that req. context (and possibly not other contexts) needs to be *active* during those invocations. Though not propagated. How it fits is that, once again, we just look if req. context is currently active when you perform RMI/async OM notification and we activate it in case it isn't. Propagation means the state would be included but activation is just about you being able to resolve the bean or getting ContextNotActiveException when you try. weld try to identify the correct pre-existing request context to associate with? Or require us to do so? The above should explain this as well - we don't perform context propagation, we only perform activation if the context isn't already active. The fact that you are using a single thread is indeed a detail, but CDI specification doesn't guarantee that the context will be either the same or different in that a case. Hence, you shouldn't rely on that. On Wed, Jun 2, 2021 at 1:09 PM Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; wrote: Thank you Matej You are correct to bring up threading, this is done on a single thread - for performance reasons WebSphere keeps both ends of an RMI on a single thread for performance reasons. But I confess this feels a little unintuitive to me. The fact we do everything on one thread feels like an implementation detail. What would happen if there was a new thread for processing an RMI? Would weld try to identify the correct pre-existing request context to associate with? Or require us to do so? When drafting this reply to you I noticed this in the spec that I missed the first time: The context associated with a built-in normal scope propagates across local, synchronous Java method calls, including invocation of EJB local business methods. The context does not propagate across remote method invocations or to asynchronous processes such as JMS message listeners or EJB timer service timeouts. Please could you help me understand how that "does not propagate" fits in what you've said before. Are you saying it really does come down to the fact we're handling RMIs on the same thread as the service() method that invokes them? Regards Benjamin From: Matej Novotny <manovotn(a)redhat.com&gt; To: Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; Cc: weld-dev(a)lists.jboss.org Date: 01/06/2021 14:27 Subject: [EXTERNAL] Re: [weld-dev] Request Scope Lifecycle and Remote EJB invocations Hello, from your description and the diagram I gather that the whole thing happens inside a single service() invocation. The thing with CDI contexts is that they are thread-bound. Your context either is or isn't active on a thread. ‍‍‍‍ Hello, from your description and the diagram I gather that the whole thing happens inside a single service() invocation. The thing with CDI contexts is that they are thread-bound. Your context either is or isn't active on a thread. CDI defines several cases for which it has to be active - such as the service() invocation or the RMI - but it doesn't say anything about the context being a new one; just active, which holds true in your scenario. Therefore, what you are seeing is IMO expected behavior. While executing the sequence of actions, you are still on one thread and the original req. context (that is activated by an actual HTTP request) is supposed to live until the service() method ends. By ending it mid-way, you'd violate its lifecycle. Not to mention that it could create some weird situations if you attempted to pause/stop/restart the same context several times in one request. Also, the same logic is applied to whenever CDI spec requires some context to be active for certain action (async events, RMI, ...) - we basically check if it already is active and only in case it isn't we activate it. That's my understanding of it, hope it helps :-) Regards Matej On Tue, Jun 1, 2021 at 11:22 AM Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; wrote: Hello I have a customer who sent me a pair of applications with the following behaviour (see also the attached flow diagram): 1. A request is sent to a REST resource in Application A 2. The endpoint makes a RMI call to ServiceB in Application B 3. ServiceB makes an RMI to ServiceA in Application A 4. ServiceA makes an RMI to ServiceB in Application B 5. ServiceB calls back to the rest resource. A @RequestScoped bean is injected into the REST Resource and Service A. The customer has noticed the same instance of that bean is injected into both injection points. They believe the two should be separate request scoped contexts. The CDI spec says the request context is alive : during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any ServletRequestListener or AsyncListener, during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB timeout method and during message delivery to any EJB message-driven bean, and But it is not clear what happens if a remote method invocation is nested inside a service() method. Is that a separate request context or the same as the parent? If they are seperate contexts, I notice that WeldInitialListener.requestInitialized requires a ServletRequestEvent, which would be tricky to acquire as part of processing an EJB remote method invocation. Would I need to find a way to access a ServletRequestEvent when creating the request context for a RMI? Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ weld-dev mailing list -- weld-dev(a)lists.jboss.org To unsubscribe send an email to weld-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU