6 Replies Latest reply on Feb 5, 2014 3:10 PM by Ron Sigal

    Preserving request context for an executor

    Ron Sigal Master

      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

        • 1. Re: Preserving request context for an executor
          Jozef Hartinger Master

          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 Master

            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
              Jozef Hartinger Master

              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 Master

                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:

                callable1.png

                callable2.png

                 

                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 Master

                  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 Master

                    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.