SeleniumLibrary load not honoring the port change request

[GoogleCodeExporter]

Mac OS X 10.6.8
Python 2.6.1
RobotFramework 2.6.2
RobotFramework-SeleniumLibrary 2.8

Our testsuites load the seleniumlibrary as follows:
Library  SeleniumLibrary  ${EMPTY} | ${EMPTY} | 4450

In the past this has worked without error but now we are seeing failures when 
suites are run back to back using different ports.

I looked in the selenium_server_log.txt and see that the default port is still 
being used.

Here is a snippet of the log:
15:59:14.925 INFO - OS: Mac OS X 10.6.8 x86_64
15:59:14.934 INFO - v2.3.0, with Core v2.3.0. Built from revision 13158
15:59:15.044 INFO - RemoteWebDriver instances should connect to: 
http://127.0.0.1:4444/wd/hub
15:59:15.045 INFO - Version Jetty/5.1.x
15:59:15.046 INFO - Started 
HttpContext[/selenium-server/driver,/selenium-server/driver]

I have also tried loading the library as follows and am getting the same error:
Library  SeleniumLibrary server_host=http://localhost:4450

Original issue reported on code.google.com by jerry57@gmail.com on 18 Oct 2011 at 11:36

[GoogleCodeExporter]

1) I don't see anything suspicious in the log snippet. How did you verify the 
library used wrong port?

2) Did you start Selenium Server as before the execution or using a keyword in 
the test data?

3) If you had exactly `Library  SeleniumLibrary  ${EMPTY} | ${EMPTY} | 4450` 
the syntax is wrong. You should have pipes everywhere or nowhere.

Original comment by pekka.klarck on 19 Oct 2011 at 9:54

• Changed state: Pending

[GoogleCodeExporter]

You are correct, I wrote out the syntax for the import wrong.  Here is the 
actual line we have been using for over a year now.

Library         SeleniumLibrary  ${EMPTY}  ${EMPTY}  4480

How we found this was that when we run our regression suites for the web tests 
back to back, every other one was failing with "Connection refused".  When I 
looked at the selenium_server.log, I found that it was using port 4444 instead 
of the port number we were assigning in the Library line.  Because we sometimes 
run our testsuites stand alone, we have to import the library for each one.  
When they are run back to back, the first doesn't free up the port fast enough 
for the second to start on the same port.  By us changing the port number each 
time, there aren't any problems.  Only now they SeleniumLibrary seems to be not 
accepting the new port number.  Even when I changed the testsuite to use the 
server_host= it still used port 4444 instead of the port number assigned.

If you would like, I will create a set of suites that will show this and the 
startup/shutdown conflict as well.

Original comment by jerry57@gmail.com on 19 Oct 2011 at 1:01

[GoogleCodeExporter]

1) In the log snippet you included the port 4444 is mentioned in instructions 
to WebDriver based clients. Was there something else that indicated that wrong 
port was used?

2) Having a simple example that demonstrates this problem would be great.

3) Have you considered starting the Selenium Server only once before execution 
and closing it afterwards? I've found this approach to be easiest in many 
situations. It also reduces the time you need to wait when the server is 
running.

Original comment by pekka.klarck on 19 Oct 2011 at 1:19

[GoogleCodeExporter]

Checkout issue #76, it talks about the port conflict and why we use different 
ports.

Original comment by jerry57@gmail.com on 19 Oct 2011 at 1:19

[GoogleCodeExporter]

I believe I have finally found where the problem lies and no it is not in the 
SeleniumLibrary code.  Sorry about the confusion here.  One of our new testers 
changed a base keyword that loads the library and consequently it wasn't 
passing the port info on the Library load.  Hence selenium-server always used 
the default port.

My apologies to all about this.  Please close the issue as non-reproducible.

Thanks,
jer

Original comment by jerry57@gmail.com on 19 Oct 2011 at 3:51

[GoogleCodeExporter]

I understood why you needed to use different ports. What I proposed was 
avoiding restarts if possible. Anyway, closing this issue as the problem was in 
your test data.

Original comment by pekka.klarck on 19 Oct 2011 at 6:49

• Changed state: Invalid