-
1. Re: Preserving request context for an executor
jharting Sep 6, 2013 9:19 AM (in response to ron_sigal)If the request attributes are preserved by RESTEasy then it would be possible to activate the request context for the Callable execution.
-
2. Re: Preserving request context for an executor
ron_sigal Jan 16, 2014 5:05 PM (in response to jharting)Hi Josef,
Thanks for your response. I'm just getting back to this issue, and I wonder if you could elaborate a bit.
I'm not sure what you mean by "request attributes" in this case. I'm looking at Chapter 19 "Managing the built in contexts" of the Weld doc, and I'm wondering if I can use something like
BoundRequestContext
. In particular, I'm thinking I would take the information from the original RequestContext bound to the first servlet call, and then somehow reuse it in a BoundRequestContext inside the execution of the Callable. But I don't see any way to do that, so maybe I'm looking at things the wrong way.Thanks,
Ron
-
3. Re: Preserving request context for an executor
jharting Jan 27, 2014 3:09 AM (in response to ron_sigal)One option is to preserve the HttpServletRequest object and activate HttpRequestContext again with the request. You would need to make sure that the beans are not invalidated at the end request though which is currently not possible without a change to Weld.
-
4. Re: Re: Preserving request context for an executor
ron_sigal Feb 4, 2014 9:45 PM (in response to jharting)Hi Jozef,
Thanks for the reply. I wanted to see if it were possible to run the job in the request scope, and it sounds like it isn't worth it.
In fact, I think that it's reasonable to run asynchronous calls in the session scope, since there is one call to the server to start the job in the background, and one or more calls to get the result. So, I've been trying to make that happen, without any success. I create a session on the first call, get a cookie back, and append the cookie to the second call. I know that's working:
20:21:51,696 INFO [stdout] (http-localhost.localdomain-127.0.0.1-8080-3) session: 9awHwv6pVaG9Csd59PEBm0na.undefined // first call
...
20:24:50,319 INFO [org.jboss.resteasy.resteasy682.AsyncTest] (http-localhost.localdomain-127.0.0.1-8080-1) cookie: JSESSIONID=9awHwv6pVaG9Csd59PEBm0na.undefined; Path=/RESTEASY-682
20:25:10,976 INFO [stdout] (http-localhost.localdomain-127.0.0.1-8080-4) session: 9awHwv6pVaG9Csd59PEBm0na.undefined // second call
I'm putting the Callable in the request scope, and I know that's working:
But I'm still getting
WELD-001303 No active contexts for scope type javax.enterprise.context.SessionScoped
when the Callable runs. I thought maybe I should have the Executor itself managed by CDI, so I put it in the the application scope, but that didn't help.
I'm running out of ideas. Do you have any suggestions?
Thanks,
Ron
-
5. Re: Re: Preserving request context for an executor
ron_sigal Feb 5, 2014 1:40 AM (in response to ron_sigal)I see what I'm missing. I need to put the Executor in the servlet context.
-
6. Re: Re: Re: Preserving request context for an executor
ron_sigal Feb 5, 2014 3:10 PM (in response to ron_sigal)Maybe what I'm trying to do isn't possible. The CDI spec says that a session scope is active
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 HttpSessionListener, AsyncListener or ServletRequestListener
So maybe a thread running an async request just isn't going to be in scope.