# 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:

```xml
<!-- 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:

```xml
<!-- 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:

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