jrobotremoteserver not working with Selenium-server
Hi-Fi opened this issue · 9 comments
I'll try to start remote server with following dependencies:
dependencies {
compile 'log4j:log4j:1.2.17'
runtime 'com.github.hi-fi:remotesikulilibrary:0.0.4.3'
runtime('com.github.markusbernhardt:robotframework-selenium2library-java:1.4.0.8')
}
remotesikulilibrary utilizes jrobotremoteserver package.
At start with ".\gradlew.bat runRemoteServer" it thows exception:
Exception in thread "main" java.lang.NoClassDefFoundError:org/eclipse/jetty/util/component/AggregateLifeCycle
Error is probably version conflict, as selenium-server uses (repacked) jetty 9.2.13.v20150730, and jrobotremoteserver relies on 7.6 series of jetty.
In test set there's both Sikuli and Selenium tests, which is why both are at dependencies.
If you change your build structure to all be compile-time dependencies (one big jar), you can utilize Gradle's dependency management to resolve version conflicts. I have done the same, but with Maven. In other words, you can force the jrobotremoteserver packaged/referenced by remotesikulilibrary to use the newer version of Jetty that has the Jetty code Selenium depends on that is missing in the older version. By default Gradle goes with the newest dependency. I have no idea if jrobotremoteserver works with that version of Jetty. Glancing at the documentation shows some promise that it will work. If I had a dev environment handy I would have tried that. Good luck.
@Hi-Fi scratch that. I tried to compile with Jetty 9.2.13.v20150730 and jrobotremoteserver will not work with that version as written.
Perhaps I need to revisit #24? Or perhaps just a newer version of this project that uses a newer version of Jetty?
I have to think on this some as I do not think there is a quick and easy solution.
@Hi-Fi taking a step back, I must ask: is it a requirement for Selenium and Sikuli to exist in the same JVM? I assume they need to be on the same machine. If they lived in different execution contexts, the version conflict would not be a problem.
Dependencies as "compile" cause different error:
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.log4j.Logger.removeAllAppenders()V
at org.robotframework.remoteserver.RemoteServer.configureLogging(RemoteServer.java:332)
at org.robotframework.remoteserver.RemoteServer.main(RemoteServer.java:134)
:runRemoteServer UP-TO-DATE
I actually made update of all dependencies to jrobotremoteserver locally, and it needed some code changes (especially because of Jetty and log4j upgrade and apache-commons new package name), but got it working. I can propably make pull request about that today.
The need for both to live in same JVM comes from tested application; it utilizes both browser and Windows GUIs, so those have to be used side by side.
Only problem with update:
With lates 9.2.x jetty test serverClosesHttp10Connections fails. I think there has been those CLOSE_WAIT issues in Jetty earlier. Not sure if that test case is in that way valid, if it tests more Jetty's functionality than library's.
With latest 9.3.x jetty all tests are passing, but that requires usage of Java8.
I think new version would be best. Maybe even moving directly to 9.3 jetty and Java8?
Just noticed your comment now. serverClosesHttp10Connections was a test to try and deal with bugs in Jython 2.5. It was not Jetty's fault if I understood correctly, but there were also issues in Jetty. Now that Jython 2.7 is out I hope it is no longer needed. Although last time I played with 2.7 and varying versions of Jetty, I saw issues with sockets closing, but they were different some how. Anyways, the bugs only seemed to be a problem when large amounts of requests were made in quick succession. The test was for a corner case reported that I do not worry about much.
It would be better to still support Java 1.7 as that is the minimum requirement for Robot Framework 3.0. But it would be better to have more releases to choose from for this project than already exist, so your proposal is fine with me.
Hi @ombre42,
I think we can make jrobotremoteserver compatible to Jetty >=9.2 with a simple change in RemoteServer class removing the use of SelectChannelConnector class that is not present in newer versions of Jetty.
It seems that we don't need to instantiate the Connector, if we use jetty Server constructor passing the port parameter. That would leave it for Jetty to decide what Connector to use, making the code compatible with older and newer Jetty versions.
Would you mind if I send you a pull request with that change?
Also I tried to deploy RemoteServerServlet to a Jetty standalone installation and to a Weblogic.
But it seems that the Servlet does not support the standard Java EE deployment descriptor (web.xml) since there is no way to populate the libraries and paths (via putLibrary method) after the Servlet is started.
Do you know any other way that I can deploy the Servlet directly to some other J2EE web app?
Thanks!
BUMP. This is also a problem for me with code I'm writing. We want a robot fwk port to be open in a program that is primarily a Jetter 9+ container. Same bug as this issue. Is the plan to fix it? Can I submit a pull request doing what @roimvargas suggested?
Has anyone implemented a change as described by @roimvargas and @ntherrien even if it isn't in this repository? If so would you be interested in sharing?
Update: I got something to work for me but it may not be a complete solution.
Fixed in release 4.0.0