[ https://issues.jboss.org/browse/SEAMCRON-2?page=com.atlassian.jira.plugin... ] Peter Royle updated SEAMCRON-2: ------------------------------- Description: Implement thread pool-based asynchronous method invocation for managed (non-EJB) beans. This feature allows developers to mark a method for background execution using an annotation. {code:java} public class BeanWithAsyncMethod { @Asynchronous public void doLongOperation() { ... } } {code} We may consider offering the task control (Future) that EJB 3.1 provides, though you can create that as a separate issue if you deem it follow-up work. See: http://download.oracle.com/javaee/6/tutorial/doc/gkkqg.html was: Implement thread pool-based asynchronous method invocation for managed (non-EJB) beans. This feature allows developers to mark a method for background execution using an annotation. {code:java} public class BeanWithAsyncMethod { @Asynchronous public void doLongOperation() { ... } } {code} To be forward thinking, we should put the @Asynchronous annotation (and related) and the dispatcher interface in Solder so that we can have different providers. For instance, Seam JMS could alternatively be used to execute the method over JMS to provide guaranteed execution instead of Seam Cron's default thread pool approach. You can use similar functionality from Seam 2 as a reference: http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_3/src/main/... We may consider offering the task control (Future) that EJB 3.1 provides, though you can create that as a separate issue if you deem it follow-up work. See: http://download.oracle.com/javaee/6/tutorial/doc/gkkqg.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMCRON-2?page=com.atlassian.jira.plugin... ] Martin Kouba reopened SEAMCRON-2: --------------------------------- AsynchronousInterceptor is not working correctly. As Marius Bogoevici commented in WELD-862 it is not quite legal to call ctx.proceed() after the interceptor method returns because the state of the interceptor chain is always restored at the end of a proceed() invocation. So in current impl the chain is proceeded two times to get to target async method in new thread. This by itself does not have to cause errors but problems occur e.g. if using other interceptors on async bean business method - also proceeded twice. What I suggest is not to call proceed() on passed InvocationContext in new thread but to inject new bean instance and execute its business method again. BTW this would be similar to Seam 2 solution (AsynchronousInterceptor, AsynchronousInvocation). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira