Research configuration deployment - Pyosch/powertac-server GitHub Wiki

[up](Deployment configurations)

This page is obsolete -- or at least moribund. The original idea for two different web apps is being replaced with a scheme having two "sides" to the visualizer web-app.

The research configuration requires two different web applications, the admin web-app and the Visualizer, to be deployed in a single servlet container, along with the simulation server. There are two obvious options for the servlet container: Jetty and Tomcat. So far, the Visualizer has been deployed with Jetty, so to begin we'll assume that the container is Jetty. The problem is that both Jetty and Tomcat create a separate classloader for each .war file, so they are isolated from each other. This is not a problem for the web-app and visualizer; they have no need to refer to each other. But they must both access the same simulation server, and it should all be in a single process space for simplicity.

Jetty allows common libraries to be loaded into $jetty.home/lib, and Tomcat accommodates this type of setup by allowing deployment of the shared content in the $CATALINA_HOME/lib directory. However, this does not solve the entire problem, because Spring must be able to see both the simulator context and the web context in order to do its dependency injection. Fortunately, Spring accommodates this problem by allowing parent-child context relationships.

Desired outcome

When the system is deployed, the following should hold:

  • Visualizer and Web-app are in separate Jetty or Tomcat web contexts, each accessible through its own URL.
  • Both Visualizer and Web-app see the (single) simulation server, because their dependencies on it have been injected by Spring and because it is in both their classpaths.
  • The Spring context is loaded in all three components; both the Web-app and Visualizer see Spring contexts that are extensions (children) of the simulator Spring context.

Deployment process

Ideally, deployment should be possible with a single maven call, just as the headless version is deployed. If this is not possible, then the instructions for deploying the setup should be simple, clear, and easily accomplished on Linux, Windows, or Mac platforms. User-specified configurations should be loaded (by default) from a directory relative to the working directory when maven is invoked, as it is in the headless version.

Packaging process

The elements of the configuration need to be individually deployable to Maven Central, in the form of jar, war, or pom modules.

One tool that might do the job is Cargo.