[cdi-dev] [JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets

arjan tijms (JIRA) issues at jboss.org
Thu Sep 29 04:21:00 EDT 2016

    [ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13300128#comment-13300128 ] 

arjan tijms commented on CDI-452:

{quote}User is logged in, and hence the user logged in state is on session{quote}

In Java EE the logged-in state is Primarily set on the request. The session may hold details that make it easier or trivial to re-authenticate each request.

{quote}We need to process several reports pertaining to the currently logged in user, of which, we have designed our API to simply allow us to inject the currently logged in user, as thus{quote}

Java EE already has the (somewhat opaque) concept of a {{security context}} being propagated, which is independent from the request, session or any other scope. This mostly comes into play when a remote EJB bean is being called, but technically also when local beans are called. JCA also has a definition for this (inflow security).

What this basically means is that when calling an asynchronous method or scheduling work on a concurrency utils thread pool, the container can make the {{Caller Principal}} and its roles available (propagates those).

If you then have say a producer for which CDI checks if your application specific {{User}} instance is already available in request scope and if not instantiates one by calling your producer method which then uses the name of the current principal, your application can pretty much function as you indicated above without the necessity to propagate the request scope.

> Specify that web scoped (request, session, application) beans are injectable in async servlets
> ----------------------------------------------------------------------------------------------
>                 Key: CDI-452
>                 URL: https://issues.jboss.org/browse/CDI-452
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Contexts, Java EE integration
>    Affects Versions: 1.0
>            Reporter: Ed Burns
>            Assignee: John Ament
>             Fix For: 2.0 (discussion)
> Consider this code based on this blog post: < https://weblogs.java.net/blog/swchan2/archive/2013/06/06/asynchronous-servlet-and-java-ee-concurrency-utilities >.
> {code}
> @WebServlet(urlPatterns="/test2", asyncSupported=true)
> public class TestAsyncMESServlet extends HttpServlet {
>     @Resource
>     private ManagedExecutorService managedExecutorService;
>     @Inject
>     MyRunnableImpl myRunnableImpl;
>     @Override
>     protected void doGet(HttpServletRequest req, HttpServletResponse res)
>             throws ServletException, IOException {
>         final AsyncContext asyncContext = req.startAsync();
>         final PrintWriter writer = res.getWriter();
>         managedExecutorService.submit(myRunnableImpl);
>     }
>     public static class MyRunnableImpl implements Runnable {
>       @Inject
>       Bean bean; // Bean is @RequestScoped
>       @Override
>       public void run() {
> 	  writer.println("Done");
> 	  asyncContext.complete();
>       }
>     }
> }
> {code}
> According to Jozef Hartzinger, this currently does not work, because only @Dependent and @ApplicationScoped beans are propagated to the new thread.  To keep CDI relevant in light of the reactive programming movement and the popularity of node.js, we need to make this work.

This message was sent by Atlassian JIRA

More information about the cdi-dev mailing list