Configure for multiple environments

Like any web app, a BladeRunner application will need to work in a number of distinct environments, for example:

  • A developer’s Machine.

  • Testing Server.

  • UAT Server.

  • Production Server (Europe).

  • Production Server (Americas).

While BladeRunner has been designed to ensure that running an app on a developer machine from source code is functionally identical to running a deployed war on a testing, UAT or production server, BladeRunner also provides developers the ability to re-configure how an application functions in different locations. There are two distinct mechanisms for this.

Development Vs War

While in development you may choose to use the built-in Jetty server, or a light-weight server like Tomcat, within production you may be required to use an enterprise level application server like Glassfish, WebLogic or WebSphere, and there may be subtle differences in how these servers need to be configured. A frequent example of this is authentication, which may seem like a nuisance in development, but may need to be enabled when the app is deployed as a war. Also, BladeRunner itself doesn’t need the bundlers configured in production (since the bundles are included in the war as flat files) but does need these servlets configured in development.

To facilitate these differences, dev specific sections of 'web.xml' can be marked up as follows:

<!-- start-env: dev -->
  <filter>
    <filter-name>cutlass-dev-filters</filter-name>
    <filter-class>com.caplin.cutlass.filter.BladeRunnerDevFilters</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>cutlass-dev-filters</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
  </filter-mapping>
<!-- end-env -->

Prod specific sections of 'web.xml' can marked up similarly:

<!-- start-env: prod
  <filter>
    <filter-name>cutlass-prod-filters</filter-name>
    <filter-class>com.caplin.cutlass.filter.BladeRunnerProdFilters</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>cutlass-prod-filters</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
  </filter-mapping>
end-env -->

Notice how the configuration within dev-only sections is left uncommented so that it is processed by development servers (that will be serving the exploded war) without a build step. Equally, notice how the configuration within dev-only sections is commented out, so it won’t be processed by a development server. During the export war task the dev-only sections are stripped completely, while the prod-only sections are uncommented.

Development Vs Testing Vs UAT Vs Production

Once an application has passed through its test suite and a war is created, it’s useful to leave the war unmodified as it migrates between environments on its way to production, since any manual modification may introduce bugs. To facilitate this, JNDI tokens and resources can be used for specifying anything that may change between environments. Typical examples of this are as follows:

  • Database Connections

  • Liberator Server URLs

  • KeyMaster Key Locations

  • Application Version

While JNDI tokens and resources can be configured/accessed within 'web.xml' as part of the J2EE specification, BladeRunner adds an additional mechanism that allows JNDI token references within HTML, JSP, XML & JSON files to be spotted, and replaced with the actual value, by using a servlet filter for this purpose. JNDI tokens can be referenced by surrounding the JNDI token name with at-symbols (@), as follows:

<base href="@APP.VERSION@"/>