Wildfly 8.1.0 Final + Arquillian 1.1.5.Final = ArquillianServletRunner - No result returned

[pawel.predki]

When I'm trying to run Arquillian tests on a remote Wildfly 8.1.0, I get the following stacktrace in the test results file:

-------------------------------------------------------------------------------

Test set: com.tellyo.rtc.test.SimpleTest

-------------------------------------------------------------------------------

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 61.214 sec <<< FAILURE!

testApplication(com.tellyo.rtc.test.SimpleTest)  Time elapsed: 1.38 sec  <<< ERROR!

java.lang.IllegalStateException: Error launching test com.tellyo.rtc.test.SimpleTest public void com.tellyo.rtc.test.SimpleTest.testApplication()

    at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:103)

    at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:109)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)

    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)

    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)

    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)

    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)

    at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)

    at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)

    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)

    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)

    at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)

    at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)

    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)

    at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:102)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)

    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)

    at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)

    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)

    at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)

    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)

    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)

    at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)

    at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:294)

    at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:269)

    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)

    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)

    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)

    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)

    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)

    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)

    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)

    at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193)

    at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)

    at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)

    at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)

    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)

    at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)

    at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)

    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)

    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:606)

    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)

    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)

    at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)

    at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)

    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)

Caused by: java.lang.IllegalStateException: Error launching request at http://0.0.0.0:7080/test/ArquillianServletRunner?outputMode=serializedObject&className=com.tellyo.rtc.test.SimpleTest&methodName=testApplication. No result returned

    at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.executeWithRetry(ServletMethodExecutor.java:139)

    at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:99)

    ... 78 more

I followed a handful of tutorials and forum topics but I couldn't find any solution to that problem and I believe I'm doing everything as I should be doing. My project consists of two ejb modules and one web module. I'm attaching the pom file of the main ejb module, the SImpleTest.java test class and also my arquillian.xml file. I'm not sure the structure of the project has anything to do with, though.

What I don't really understand is why the request in the exception above is launched at 0.0.0.0.

I can see in the server logs that the test application is indeed deployed:

2014-08-05 17:00:26,831 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /opt/wildfly/standalone/data/content/f6/1fe7d564c3ef44a17443920a1b8a201787eb19/content

2014-08-05 17:00:26,848 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "test.war" (runtime-name: "test.war")

2014-08-05 17:00:27,236 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment test.war

2014-08-05 17:00:27,492 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: test.war

2014-08-05 17:00:27,585 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment test.war

2014-08-05 17:00:30,595 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017534: Registered web context: /test

2014-08-05 17:00:30,812 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "test.war" (runtime-name : "test.war")

2014-08-05 17:01:14,637 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017535: Unregistered web context: /test

2014-08-05 17:01:14,674 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016009: Stopping weld service for deployment test.war

2014-08-05 17:01:14,769 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment test.war (runtime-name: test.war) in 139ms

2014-08-05 17:01:15,008 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /opt/wildfly/standalone/data/content/f6/1fe7d564c3ef44a17443920a1b8a201787eb19/content

2014-08-05 17:01:15,014 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "test.war" (runtime-name: "test.war")

I don't know, though, why it's deployed as test.war, even though i specify a different name in the ShrinkWrap.create method in my SimpleTest class.

Another thing suspicious in the log file is this:

2014-08-05 16:38:08,561 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:7080

Why isn't Undertow assigned a proper IP address? Is this the way it's supposed to be?

Any help would be appreciated!

[rcd]

My guess is that your WildFly configuration has the public interface bound to 0.0.0.0. Could also be that the jboss.bind.address system property is set to 0,0.0.0 or something is passing -b 0.0.0.0 on startup.

Binding to 0.0.0.0 is a bad practice IMO. It's the most likely cause of your problem, and I've seen it cause problems with some WildFly components (e.g. JGroups) in the past. You're much better off setting it to a real IP address, or using one of the other choices for selecting a binding. Note that subnet-match is currently broken but is fixed for 8.2.

[pawel.predki]

I looked into the server startup logs and both the jboss.bind.address and jboss.bind.address.management are set to non-zero values. I'm setting the host name of the machine instead of the IP address but I don't think this is incorrect.

The undertow configuration in standalone.xml is as follows:

<subsystem xmlns="urn:jboss:domain:undertow:1.1">

            <buffer-cache name="default"/>

            <server name="default-server">

                <http-listener name="default" socket-binding="http"/>

                <host name="default-host" alias="localhost">

                    <location name="/" handler="welcome-content"/>

                    <location name="/playlist" handler="playlist"/>

                    <filter-ref name="server-header"/>

                    <filter-ref name="x-powered-by-header"/>

                    <filter-ref name="access-control-allow-origin-header"/>

                </host>

            </server>

            <servlet-container name="default" default-encoding="UTF-8">

                <jsp-config/>

            </servlet-container>

            <handlers>

                <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>

                <file name="playlist" path="/home/appserver/CopiesGrabsTS/" directory-listing="true"/>

            </handlers>

            <filters>

                <response-header name="server-header" header-name="Server" header-value="WildFly/8"/>

                <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>

                <response-header name="access-control-allow-origin-header" header-name="Access-Control-Allow-Origin" header-value="*"/>

            </filters>

        </subsystem>

What other binding could interfere here? Should I look into setting some values for Undertow, too?

[rcd]

Post your interface and socket-binding-group sections. Undertow is configured to use the "http" socket-binding in the XML you posted above, so you can determine which interface it should be bound to by looking at that. By default, the http socket-binding is configured to use the default interface, which is "public", and public is bound to whatever is specified in the jboss.bind.address system property, or 127.0.0.1 if that property is not specified.

[pawel.predki]

socket-binding-group:

	<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
	<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:7990}"/>
	<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:7993}"/>
	<socket-binding name="ajp" port="${jboss.ajp.port:7009}"/>
	<socket-binding name="http" port="${jboss.http.port:7080}"/>
	<socket-binding name="https" port="${jboss.https.port:7443}"/>
	<socket-binding name="txn-recovery-environment" port="4712"/>
	<socket-binding name="txn-status-manager" port="4713"/>
	<socket-binding name="messaging" port="5445"/>
	<socket-binding name="messaging-throughput" port="5455"/>
	<outbound-socket-binding name="mail-smtp">
	<remote-destination host="localhost" port="25"/>
	</outbound-socket-binding>
	</socket-binding-group>

old interfaces:

	<interfaces>
	<interface name="management">
	<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
	</interface>
	<interface name="public">
	<any-address/>
	</interface>
	<interface name="unsecure">
	<inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
	</interface>
	</interfaces>

I changed the any-address to:

    <inet-address value="${jboss.bind.address.management}"/>

And it works! Thanks for pointing me in the right direction!

My question is, is this some kind of security threat binding the management address to the public interface? I'm not really sure what this is used for and if it leaves some vulnerability?

[rcd]

The default value for the public interface is:

<inet-address value="${jboss.bind.address:127.0.0.1}"/>

I'd suggest not using jboss.bind.address.management because in production, you'll probably want the public interface to be different from the management interface (e.g. public on a WAN port, management still on localhost so people can't mess with your server).

[pawel.predki]

This is getting slightly off-topic now but this is something I would also like to understand. If I understand correctly if I keep the management on localhost I won't be able to use the Remoting features, e.g. deploying the application directly from Eclipse. Is that correct?

Also, in the arquillian.xml file it is required to use the managementAddress and managementPort, as well as the Management Realm username and password, to connect to the remote Wildfly instance. Doesn't this mean that it needs to management binding to work and changing it to localhost will break it?

[rcd]

Whether Arquillian and Eclipse deployments will work depends on your setup. Where I work, every developer sets up a WildFly instance on their own system, so binding to localhost is perfectly fine because Eclipse and Arquillian run on the same system. In fact, I usually have the "public" interface bound to localhost as well. This is especially useful when working on clustered applications, as binding to localhost will isolate your WildFly instance from everyone else's and you can be sure you have your own sandbox to play in.

Arquillian has the concept of "managed" and "remote" containers. A managed container is started and stopped by Arquillian as part of the test, so it has to run on the same system. A remote container can be on any system, but Arquillian doesn't manage the container's lifecycle (start/stop), it only deals with deploying/undeploying.

The bottom line is that the management interface lets you do anything. You can use it to stop or restart the server, trigger deploys and undeploys, and change practically any setting. It's extremely powerful, but that also means you have to be careful where you expose it. It does have authentication mechanisms to help with this, but you need to set up users. I don't have much experience with that as we always deploy in standalone mode with management on localhost.

[pawel.predki]

I understand. We don't have a large team at the moment so we work on a single remote machine, where we develop two different applications so we're not stepping on each other's toes. In this setup we have to use the management interface, with the Management Realm users, as you mentioned. That's why we run the Arquillian tests using the remote profile - it connects to the remote Wildfly instance, deploys the test archive, runs the tests and undeploys the archive. Having said that, as we grow larger I also believe we will work on our local machines and all your comments become useful at that moment, thank you.