I have created on my account because I can work and rework freely and then when we decide to push to arquillian account I will be able to squash all commits into one called initial commit, so it is easy for all of us.

I have named the extension cube for two reasons:

because docker is like a cube

and because borg starship is named cube and well because we are going close to production we can say that any resistance is futile, bugs will be assimilated. Moreover we still have some references to space.

I have just created a first version of a yaml file to configure a docker container. I have decided to use a yaml file instead of properties inside arquillian.xml because of the huge number of parameters that may be configurable.

From arquillian.xml you will be able to provide location of this configuration file, or even paste it as embedded data.

Thanks a lot for your effort. I am to late for going through all comments. My POC was based on Docker Java and it worked so far but had very little functionality. You are for sure much further with the development.

I jumped in a docker evaluation because we do have many CI test conflicts between junit runs at the same time. And docker is an answer for this issue:-) Basically the steps are:

Precondition: Docker is installed on a remote server (a very powerful one!)

An Arquillian docker extension connects to this remote docker service, starts the container with the given image

Inside the docker container instance is now a java ee container running (based on the image)

Hi guys, I need some of your advice or if you have any other idea about a problem I have found today.

Docker API provides a method to wait until the container is started, so basically you use wait function and you wait until docker server sends you that the container is up, and then the method is unblocked and you can be sure that you can use it. The problem with this method is that it only works if the server you requires from container (let’s say a MongoDB) is started in background and as daemon. But in general java servers cannot use this approach inside Docker; they must start in foreground. If you see Wildfly container, Tomcat container and so on you will see that they are executed using CMD operator. So server is started on foreground and the server can start correctly. If you do not this, Docker container is executed but don’t start the server.

So wait approach doesn’t work because the container never ends. So we need another approach. My first idea was to open a socket on required host and port and if an exception is thrown I retry. But this approach has one problem and is that when docker is starting up it does some port forwarding so when this ping is executed the ping returns true so it seems that server is is up, but this is not true, Tomcat in that case is not up and the file cannot be deployed. I think that this is because Docker container opens the port to do the port forwarding and although server is not up the socket can be opened so no exception is thrown. I know that it is a bit difficult to explain, but basically if I do an sleep it works but if I add the approach it doesn’t work and Arquillian says that cannot deploy the deployment file because server is not up.

So I have thought that maybe user should be able to set which approach to use to wait until docker is up.

Native wait: which is the native way of waiting

Sleep: which is an fix sleep time

Command Line inspect: you add a reg exp. and until this regular expression does not return true from the console log of docker container.

Sure the problem is that docker server opens the port so the socket returns true although in reality the container within the Docker server (in my case the app server) is not already started. I think that spacelift guys has similar problem (not becuase of docker but because OS). So I will try to use similar approach as well

Found a solution, meanwhile the container is starting up I poll until it is assigned the ip address of the bootup container. In this way I don’t use port forwarding and I can be sure that socket works as expected. I am not sure that this approach will work when using boot2docker, but for now in Linux works as expected.