[weld-dev] Re: 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.
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>
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.
6.
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
1.
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
Attachments:
- attachment.html (text/html — 4.5 KB)