-
Notifications
You must be signed in to change notification settings - Fork 33
Frequently Asked Questions
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.
The server
field can be accessed by sub-classes of RemoteServer
and allows customizing the web server. Below demonstrates creating a thread pool, making it non-daemon, and assigning it to the server. This will prevent the remote server from keeping the JVM from shutting down if there are no non-daemon threads. See also Jetty API documentation
import org.eclipse.jetty.util.thread.QueuedThreadPool;
public class ServerStarter {
public static void main(String[] args) throws Exception {
RemoteServer server = new RemoteServer() {
{
QueuedThreadPool pool = new QueuedThreadPool();
pool.setDaemon(true);
this.server.setThreadPool(pool);
}
};
server.start();
}
}
You can if you are using version 3.0 or above.
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.
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.