JBoss and Selenium - no love at first sight

Blog
1

Few days ago, I encountered some difficulties in setting up Selenium tests for a webapp running in JBoss. There was only one issue, actually, but it was a big one and it was hard to find. Here I’ll describe the symptoms and explain how to remedy this problem.

The Issue

I'm using maven Cargo to launch JBoss, and the selenium maven plugin to launch the Selenium server. Jboss and Selenium are on the same machine.

Unfortunately, even though Selenium said that it started and that Jboss launched succesfully in the cargo container…

Selenium Server started [INFO] [cargo:start {execution: start-container}] [INFO] [surefire:test {execution: default}]
...all tests failed :s

In the surefire report, there is a mysterious error:

java.lang.RuntimeException: Could not start Selenium session: � at com.thoughtworks.selenium.DefaultSelenium.start(DefaultSelenium.java:89) at org.bonitasoft.selenium.module.SeleniumBaseUtil.SeleniumBaseUtil.setUp(SeleniumBaseUtil.java:41) at org.bonitasoft.selenium.testcase.UserXPAdminCasesTest.setUp(UserXPAdminCasesTest.java:41) at junit.framework.TestCase.runBare(TestCase.java:128) at com.thoughtworks.selenium.SeleneseTestCase.runBare(SeleneseTestCase.java:212) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:228) at junit.framework.TestSuite.run(TestSuite.java:223) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: com.thoughtworks.selenium.SeleniumException: � at com.thoughtworks.selenium.HttpCommandProcessor.throwAssertionFailureExceptionOrError(HttpCommandProcessor.java:97) at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:91) at com.thoughtworks.selenium.HttpCommandProcessor.getString(HttpCommandProcessor.java:262) at com.thoughtworks.selenium.HttpCommandProcessor.start(HttpCommandProcessor.java:223) at com.thoughtworks.selenium.DefaultSelenium.start(DefaultSelenium.java:81) ... 21 more
Have you ever encountered this error? And would you like to have the solution? Well then, yes of course I will give it :)

The Remedy

It seems that JBoss and Selenium, by default, are both using port 4444!! As we are testing a webapp on a specific JBoss, I prefer to modify the port used by Selenium. You can do this in the maven selenium plugin:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>selenium-maven-plugin</artifactId> <executions> <execution> <id>start</id> <phase>pre-integration-test</phase> <goals> <goal>start-server</goal> </goals> <configuration> <port>4447</port> </configuration> </execution> <execution> <id>stop</id> <phase>post-integration-test</phase> <goals> <goal>stop-server</goal> </goals> <configuration> <port>4447</port> </configuration> </execution> </executions> </plugin>
In the java code that executes the Selenium tests, you also need to use the same port:
new DefaultSelenium(serverHost, 4447, browserStartCommand, browserUrl);
Why did I choose 4447, you may ask. It's simple: JBoss also uses ports 4445 and 4446 . Another reason is that Tomcat doesn't use this port and AFAIK no other Application Servers uses it either.

Note: I’ve opened a bug request to provide better feedback when this exception is encountered.