Preserving request context for an executor

[ron_sigal]

Resteasy has a home grown asynchronous facility in which the server puts a Callable into an executor and returns status 202 with a URI in a Location header.  That URI can be polled for a result.

In https://issues.jboss.org/browse/RESTEASY-682 it is reported that when the request is made on a JAX-RS resource in the request scope, the attempt to execute the Callable results in the exception "org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped".  It makes sense, since the original servlet request has already exited.

Is there any way to preserve the request context?  Or is the only solution to use application scope (or maybe session scope)?

Thanks,

Ron

[jharting]

If the request attributes are preserved by RESTEasy then it would be possible to activate the request context for the Callable execution.

[ron_sigal]

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

[jharting]

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.

[ron_sigal]

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

[ron_sigal]

I see what I'm missing. I need to put the Executor in the servlet context.

[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.