Application

This document is referring to a past Scout release. Please click here for the recent version.

This section describes the module structure of a Scout application and how the bootstrap is initiated.

Module structure

For each server (typically there is one server for Scout JS and two servers, UI and backend, for Scout Classic applications), the following modules are used to build or run the application:

Each leaf module (.dev, .image, .zip) contains a config.properties, logback.xml and possible other resources relevant for the corresponding build/application run. Dependencies only relevant for a certain build (e.g. development) must only be added in the corresponding module. Dependencies relevant for all builds should be placed in the .app module.

Bootstrap Class

org.eclipse.scout.rt.app.Application is the main class to bootstrap a Scout application. This is the class started via run configuration in your IDE as well as the one used within the Docker Image (.app.image) or the shell scripts within the ZIP build (.app.zip).

Besides starting the platform, the main class takes care of running an embedded Jetty application server, so that your application is accessible via browser.

Servlet (Filter) Contributors

Own servlets or servlet filters are registered by providing an implementation of:

  • org.eclipse.scout.rt.jetty.IServletContributor

  • org.eclipse.scout.rt.jetty.IServletFilterContributor

For .war deployments on an application server (e.g. Tomcat) a servlet (filter) registration is configured via web.xml. The registration described above is the programmatic equivalent for the Scout application.

It’s a good practice to put the implementing class as static inner classes within a container class in the .app module (i.e. ServerServletContributors, UiServletContributors or AppServletContributor as generated by the Scout archetype).