1 of 1 people found this helpful
If Arquillian is managing the container, then Arquillian would start the container before proceeding to generate the deployment. If the container is not managed by Arquillian, e.g. remote containers, then there is no such guarantee.
When remote containers are used for testing, it would be preferable to start the container before the tests are run. This is more or less to prevent a race condition where the container would not have started, by Arquillian attempts to run the tests. Some container extensions, like Tomcat attempt to handle this scenario by waiting for the container to be availble, but I cannot speak for all supported containers.
Also, I'm not sure if there is a "guarantee" in this area for managed containers - the SPI docs for DeployableContainer do not specify that deploy() will be invoked after start(). The way I read the docs, this is more or less an implementation detail. Aslak would be the best person to answer this.
If your concern is that Arquillian would attempt to deploy and run the tests before the queue is added, then that would depend on whether ResourceDeployer.addQueue is a blocking call. Arquillian packages and deploys an archive containing the Deployment only after the @Deployment method has returned.
thanks for your reply!
In our case it is Arquillian that is managing the container so I think we might be able to use this approach for now.
A Container that is managed by Arquillian will be started at this point.
Thank you both for your help!