Frequently Asked Questions

Why isn't jrobotremoteserver a runnable jar?

The system ClassLoader when using a runnable jar intentionally ignores the CLASSSPATH environmental variable as well as any jvm arguments pertaining to classpath. jrobotremoteserver would not be able to find/load your classes without implementing a custom ClassLoader that uses the CLASSPATH variable.

Why can't I overload my keyword methods in a static API library?

jrobotremoteserver uses Javalib Core to support static API libraries, which is limited to one method per keyword. Should Javalib Core be enhanced to support overloaded keywords, jrobotremoteserver will be updated to use the newer version.

Where is the log output from Jakarta Commons Logging?

Javalib Core has a properties file that configures JCL to use a no-op logger. Use RemoteServer.configureLogging(), make your own properties file that replaces the existing one, or configure JCL at runtime to avoid using the no-op logger.

Can I have multiple Robot Framework instances utilizing jrobotremoteserver simultaneously?

Yes, but there are some things you should be aware of. As implemented, only one instance of a test library is used. This means the library needs to be thread safe. A future enhancement could have per-client address instances, but that is not done yet. You could try replacing the servlet to accomplish that. Also consider using the static method getRequest() in org.robotframework.remoteserver.servlet.RemoteServerServlet if you want to differentiate between different clients. Unless Robot Framework uses the same source port, it will be impossible to differentiate multiple instances of RF on the same machine.