[ https://issues.jboss.org/browse/ARQ-626?page=com.atlassian.jira.plugin.sy... ] Aslak Knutsen commented on ARQ-626: ----------------------------------- When using async components you are moving the execution over to another thread, which is outside of Arquillians reach. In these cases the TestClass has to 'wait' one way or the other for the async execution to finish before moving on. This can be done by using e.g java.util.concurrent.Latches. See the cdi-ejb async example in the showcase: https://github.com/arquillian/arquillian-showcase/blob/master/cdi-ejb/src... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ARQ-626?page=com.atlassian.jira.plugin.sy... ] Hugo de Paix de Coeur edited comment on ARQ-626 at 10/9/11 5:30 AM: -------------------------------------------------------------------- Yes .. I had written such a workaround (thanks for CountDownLatch I didn't know). I agree we must sync by our own means a "user" thread, but I was hoping "managed" threads (JMS, or Async EJB) could have been tracked by the glassfish containers for us and the glassfish-embedded to handle it. It seems it's more an enhancement than a bug. was (Author: kabhal): Yes .. I had written such a workaround (thanks for CountDownLatch I didn't know). I agree we must sync ourself by our own means a "user" thread, but I was hoping "managed" threads (JMS, or Async EJB) could have been tracked by the glassfish containers for us and the glassfish-embedded to handle it. It seems it's more an enhancement than a bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira