ENTRY

"Fighting with Selenium. SeleniumException … ERROR: Unknown command"

Date:July 12th, 2011
Tags:
Comments: 0

During the test migration between two Hudson instances, I got this weird problem.

Selenium was constantly complaining, that it doesn’t know the command (ERROR: Unknown command):

14:43:48,607 INFO [org.openqa.selenium.server.SeleniumDriverResourceHandler] Command request: setAttribute[user, slave1] on session 8c48d33ab9654615b2cc07cc5135a283
14:43:48,620 INFO [org.openqa.selenium.server.SeleniumDriverResourceHandler] Got result: ERROR: Unknown command: 'setAttribute' on session 8c48d33ab9654615b2cc07cc5135a283
Apr 29, 2010 2:43:48 PM sun.net.www.protocol.http.HttpURLConnection getInputStream
FINE: sun.net.www.MessageHeader@1efb4be8 pairs: {null: HTTP/1.1 200 OK}{Date: Thu, 29 Apr 2010 12:43:48 GMT}{Server: Jetty/5.1.x (Linux/2.6.27.4-mylinx.lenny i386 java/1.6.0_14}{Cache-Control: no-cache}{Pragma: no-cache}{Expires: Thu, 01 Jan 1970 00:00:00 GMT}{Content-Type: text/plain}{Content-Length: 38}
ERROR Error starting browser (*firefox). com.thoughtworks.selenium.SeleniumException: ERROR: Unknown command: 'setAttribute'
com.thoughtworks.selenium.SeleniumException: ERROR: Unknown command: 'setAttribute'
 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 mytests.test.WebSelenium.setAttribute(WebSelenium.java:42)
 at mytests.test.WebTestBaseTest.start(WebTestBaseTest.java:65)
 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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644)
 at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443)
 at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160)
 at org.testng.internal.Invoker.invokeMethod(Invoker.java:494)
 at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700)
 at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002)
 at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137)
 at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)

 
The solution was simple. Obviously, the old server was running Jetty 6.x, and the new server was starting under Jetty 5.x. The older servlet api version didn’t support the session.setAttribute method.

Why was the new “cloned” Hudson running another Jetty. Well, new server was ‘headless’ and I needed to use Xvfb to enable browser support. First time I did it by adding selenium-maven-plugin to my maven pom.xml. That started the Xvfb but also an extra jetty version, the wrong one I might add:

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>selenium-maven-plugin</artifactId>
        <executions>
            <execution>
                <id>xvfb</id>
                <phase>pre-integration-test</phase>
                <goals>
                    <goal>xvfb</goal>
                </goals>
                <configuration>
                    <display>:1</display>
                </configuration>
            </execution>
                         <execution>
                <id>selenium</id>
                <phase>pre-integration-test</phase>
                <goals>
                    <goal>start-server</goal>
                </goals>
                <configuration>
                    <background>true</background>
                </configuration>
            </execution>
        </executions>
    </plugin>



The better way to handle the problem was to start Xvfb on the headless system directly (and then make sure it is always running). That solved the problem. By removing selenium-maven-plugin from my pom.xml I also get rid of SeleniumException … ERROR: Unknown command.

RELATED
Pages
Posts


Responces

Leave a Reply