[JBoss JIRA] (CDI-535) cdi instance injection ordering
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-535:
-------------------------------------
Or add a priority method to @Produces? I prefer the @Priority annotation tbh
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0 (discussion)
> Reporter: Ochieng Marembo
> Priority: Optional
>
> We should allow ordering of bean instance injection using the ```Instance<MyBeanInterface>``` when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance<MyBeanInterface>{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code}
> {code}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-535) cdi instance injection ordering
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-535:
-------------------------------------
Or we could introduce this feature for what @Priority has for now and in a later spec update support producer methods?
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0 (discussion)
> Reporter: Ochieng Marembo
> Priority: Optional
>
> We should allow ordering of bean instance injection using the ```Instance<MyBeanInterface>``` when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance<MyBeanInterface>{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code}
> {code}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-535) cdi instance injection ordering
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-535:
-------------------------------------
Good point. Can we enhance the Priority annotation or would that take ages to be accepted?
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0 (discussion)
> Reporter: Ochieng Marembo
> Priority: Optional
>
> We should allow ordering of bean instance injection using the ```Instance<MyBeanInterface>``` when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance<MyBeanInterface>{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code}
> {code}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-535) cdi instance injection ordering
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-535:
----------------------------------
One problem with {{javax.annotation.Priority}} is that its {{@Target}} is currently only TYPE (unfortunately Commons Annotations 1.3 MR only adds PARAMETER). So we will not be able to add priority to producer methods and fields.
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0 (discussion)
> Reporter: Ochieng Marembo
> Priority: Optional
>
> We should allow ordering of bean instance injection using the ```Instance<MyBeanInterface>``` when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance<MyBeanInterface>{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code}
> {code}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-535) cdi instance injection ordering
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-535?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-535:
-------------------------------------
This is really interesting and useful. Can this make it to CDI 2.0 ?
> cdi instance injection ordering
> -------------------------------
>
> Key: CDI-535
> URL: https://issues.jboss.org/browse/CDI-535
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0 (discussion)
> Reporter: Ochieng Marembo
> Priority: Optional
>
> We should allow ordering of bean instance injection using the ```Instance<MyBeanInterface>``` when an instance injection is used.
> h3. Use case:
> Developer always define a kind of chain of processor beans, which may need to run in specific order.
> h3. Current scenario:
> Using the Instance injection mechanism, a developer can inject multiple beans implementing the same interface and iterate of them. In order to ensure ordering, the developer could do one of the following:
> #1
> {code}
> private Iterable<MyBeanInterface> myBeans;
> @Inject
> void injectBeans(@Any Instance<MyBeanInterface> myBeans) {
> //the create order does some kind of ordering on the beans.
> this.myBeans = createOrder(myBeans);
> }
> {code}
> #2
> This second option may be expensive if we have to order the beans everytime we execute the logic, and if this bean is applicationscoped, it wont make sense to do the ordering in the method call.
> {code}
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> public void doSomething() {
> Iterable<MyBeanInterface> orderedbeans = createOrder(myBeans.select(someQualifier));
> }
> {code}
> h3. Our Proposal
> We already have {code}javax.annotation.Priority{code} or any cdi specific annotation which we can add to {code}MyBeanInterfaceImpl{code} so that on injection of an {code}Instance<MyBeanInterface>{code}, all possible injection values are sorted based on the {code}Priority.value(){code} and if no annotation is defined, defaults to {code}Priority.value = Integer.MAX_VALUE{code}
> {code}
> public interface MyBeanInterface {}
> @MyQualifier
> @Priority(0)
> public class MyFirstBean implements MyBeanInterface{
> }
> @MyQualifier
> @Priority(2)
> public class MySecondBean implements MyBeanInterface{
> }
> @ApplicationScoped
> public class MyBeanProcessor {
> //We expect that this injected instances shall be in order based on the @Priority annotation
> @Any
> @Inject
> private Instance<MyBeanInterface> myBeans;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
Recap of Context Management (CDI-30) hangout meeting
by Antoine Sabot-Durand
Hi all,
Just to sum up what was said during our Tuesday Hangout meeting. For those
who were present feel free to correct or amend this.
Controlling Request Context is something rather easy (because it's linked
to one thread) while Session Context is far less obvious (used across
multiple threads) so providing a generic solution to deal with their
control seems quite complicated.
That's why we decided to start addressing the Request Context control first
and if we fell happy with that, continue the work on the Session Context.
Public API to control the request context could be design in 2 different
ways:
1) provide an interceptor to activate request context during the
intercepted method invocation
2) provide a programmatic API accessible thru a bean (like the Conversation
bean)
First solution is probably the easiest way for end user (to avoid not ended
context), but if we go for controlling Session Scope we won't be able to
provide a simple interceptor for it and will design something like solution
2 for it.
So the question is should we go for 1 or 2 or both (with a risk of
confusion) ?
Thanks for your feedback
Antoine
8 years, 2 months
[JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.sy... ]
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-ser... >.
> {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)
8 years, 2 months
[JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-452:
----------------------------------------
+1, also note that not propagating the main context makes it pretty useless. Takes a simple and very common use case where you have a security filter pushing data in a request scoped bean (display name, login etc...) and a @Suspended jaxrs endpoint then no way to get the filter data. This is not only about EE concurrency but a way to let user propagate properly a context - then thread safety etc is up to him. So we need a cdiWhatever = enterContext(scope); ....; exitContext(cdiWhatever);
There are really no technical blocker for that and would make context far more powerful in nowadays world using more and more such a things.
> 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-ser... >.
> {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)
8 years, 2 months
[JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets
by Ochieng Marembo (JIRA)
[ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.sy... ]
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-ser... >.
> {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)
8 years, 2 months
[JBoss JIRA] (CDI-452) Specify that web scoped (request, session, application) beans are injectable in async servlets
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-452?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-452:
----------------------------------
I think there are basically two questions here:
# Should the request context be active during a Concurrency Utilities task execution
# Should the request be also propagated (as defined in [6.3. Normal scopes and pseudo-scopes|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#normal_scope])
I'm +1 for context activation but -1 for context propagation - the same applies to EJB asynchronous method invocations, timers and JMS message listeners (see also [6.7. Context management for built-in scopes|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_contexts]).
> 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-ser... >.
> {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)
8 years, 2 months