I'm trying to setup a jenkins master that kicks off a SSH-communicating docker slave that runs arquillian cube for starting a postgresql-test-db and launching a WildFly through a remote connector.

I've tried mapping the docker socket to the slave container and using a unix:///var/run/docker.sock for dockr serverUri in arquillian.xml but apparently dockerjava still insists on calling the Docker REST endpoint since I get a stacktrace of

java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor

What I'm not getting is that it appears to be the WildFly module loader that doesn't pick up some module but where does it get that module from? In WildFly 12 there is no such module(?) so providing that dependency through jboss-deployment-structure.xml is not going to work anyway, right?

Am I using some wrong version of something(tm) and Cube is passing in something old into the dockerjava DockerClientBuilder?

The strange thing is that even if I have the serverURI defined as socket (and I can see it outputted when cube starts), dockerjava still insists on using the REST-integration. And the container has access to the socket, I've tested that by ssh:ing into the container and doing a curl against it. I've also modified the image to run a simple dockerjava test program and that works, too.

I tried including the RESTeasy client jars into the test archive but it started crying about not being able to handle the json-response and adding jersey too didn't help for some reason so I did a fallback to mounting the socket...

I have a similar problem here with the module (that does not exist in WFLY 14) not being found, I think I must have a misconfiguration but I am not sure what would trigger needing that module. Tried to look in the code for Arquillian but can't find the reference in the repo I looked in.

Did you solve your problem yet? It might help me to modify my code to resolve mine hopefully

So, to shed some light on the issue here, the jboss fork of the jax-rs api spec jar is being used here. One of the minor changes it has compared to the vanilla version is that it adds a mechanism for using JBoss Modules to detect if RESTEasy is available when trying to build one of the jaxrs factories. That mechanism is triggered when no jax-rs implementation is found using 1) the context classloader, 2) $java.home/lib/jaxrs.properties, 3) the proper system property ("javax.ws.rs.client.ClientBuilder" in the case here). The vanilla api fallbacks on Jersey implementation, our api used to fallback to resteasy implementation before JBEE-169 was implemented and is now running the jboss modules mechanism above before fallbacking to Jersey implementation.

As to why the module is not there, that's another involved story related to the upgrade of WildFly to RESTEasy 3.1 series which was performed and then rollbacked (currently the jaxrs resolution is effectively controlled by the context classloader on the container if I remember properly, which is also why adding the resteasy-client artifact dependency as mentioned above fixes the problem).

Speaking of workarounds, you could also set the javax.ws.rs.client.ClientBuilder system property (it's not what you tried above).

What should the javax.ws.rs.client.ClientBuilder be set to? I tried with <javax.ws.rs.client.ClientBuilder>org.glassfish.jersey.client.JerseyClientBuilder</javax.ws.rs.client.ClientBuilder> but not go.

Actually it's a bit confusing since If I use some dummy value it fails, proving the setting is picked up. But if I use the JerseyClientBuilder, I see no reference to it (or to j.w.r.c.ClientBuilder) in the stacktrace.

The stack is

Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.resteasy.resteasy-jaxrs-api
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:285)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.ws.rs.ext.FactoryFinder.getModuleClassLoader(FactoryFinder.java:252)
at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:205)
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:136)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:120)
at javax.ws.rs.core.UriBuilder.newInstance(UriBuilder.java:95)
at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119)
at org.glassfish.jersey.client.JerseyWebTarget.<init>(JerseyWebTarget.java:71)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:290)
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:76)
at com.github.dockerjava.jaxrs.JerseyDockerCmdExecFactory.init(JerseyDockerCmdExecFactory.java:237)
at com.github.dockerjava.core.DockerClientImpl.withDockerCmdExecFactory(DockerClientImpl.java:161)
at com.github.dockerjava.core.DockerClientBuilder.build(DockerClientBuilder.java:47)

Apparently it is used but at some point still hits the module class loader from the jboss-jaxrs-api or something

I can confirm that the fix works "in the wild". I compiled the change and threw it into the local repo of the build machine. It required upgrade to the EE8 API though so it would be nice to know of any other potential workarounds untils it hopefully makes the EE 8 Alpha2 spec API.

Regarding the workaround, I would have expected <javax.ws.rs.client.ClientBuilder>org.glassfish.jersey.client.JerseyClientBuilder</javax.ws.rs.client.ClientBuilder> to work, maybe the Jersey client builder does not really have that FQN ?