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

[Ochieng Marembo (JIRA)]

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

Ochieng Marembo commented on CDI-452:
-------------------------------------

In my opinion, i think the case for context-propagation is still of noteworthy here. Consider the following scenarios:

1. User is logged in, and hence the user logged in state is on session
2. 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

{code:java}
@Inject
private User loggedInUser;
{code}
3. Assume to generate this report, we need to communicate with 3 or so external services which requires currently logged in user, hence, the services may look like this:
{code:java}

@ApplicationScoped
public class UserOrderService {

    @Inject
    private Instance<User> loggedInUser;

    List<Article> getOrderArticles() { //External service call }
}

@ApplicationScoped
public class UserCartService {
    
    @Inject
    private Instance<User> loggedInUser;

    List<Article> getArticlesInCart() { //External service call }
}

@ApplicationScoped
public class UserWishlistService {
    
    @Inject
    private Instance<User> loggedInUser;

    List<Article> getArticlesInWishlist() { //External service call }
}
{code}
4. We want to invoke this services, asynchronously. Of course we can simply pass the user context as parameters of the methods, but then, we will need to pass it on every possible method, just in order that it ends up where it is required. Other methods will unnecessarily be accepting a parameter, just in order that someone down the trail may need it.
5. It is up to the developer, to ensure that the execution of the async calls, all complete if their results are needed for the response. 
6. We can also design the asynchronous task to be long-running, so that we fire and forget, and the response can be sent to client if and when the required async calls are complete, ignoring all async calls marked as long-running (or fire-and-forget)
7. The CDI current inability to propagate request/session contexts to async calls, (and equivalently the ejb @Asynchronous) makes it practically impossible to perform several tasks within a single request that requires current request context, making CDI services hugely slow, and not using the processing power of CPU, unless one resorts to complicated parameter based context passing, which is really inconveniencing. 

> 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
(v6.4.11#64026)