Tomcat In Development, Test and Production Environments
This post shows how a JVM variable can be employed on Tomcat’s startup command to declare a server instance as either a development server, a test server or a production server. An application can then retrieve this value during its startup processing phase to determine the database to which a connection must be made. To see how EGL can read this JVM variable value select this link.
Variable Indicating Development, Test and Production Servers
The value assigned to the parameter “runtimeEnvironment” indicates the role of the Tomcat server. For the developer’s server, usually running inside the IDE (RDi) the value for this parameter will be “localhost”. For the test and production Tomcat servers running on the iSeries, there are two valid values which are “TEST” and “PROD”. For example this parameter will designate the server as a production server:
All applications should obtain the value of this variable during its startup phase. For Java, this is a startup servlet. For EGL, it will be a service.
Shown below is the command that starts a Tomcat server. It has been modified to set the environment variable and its value, in this case, ‘PROD’.
All parameter name/value pairs begin with “-D”.
Why Do This?
The intent is to inform the application about the role of the server, i.e. the developer’s desktop machine in which case the value will default to “localhost” for the developer’s server, “TEST” for the test server and “PROD” for the production server. Once the value is obtained the application’s logic can then determine the proper database connection to use in addition to reading the correct set of property values established for the application. The diagram shown clarifies this.
This post revealed how a name/value pair can be established for a given Tomcat server instance so that an application may interrogate the value of the named parameter. With the value obtained the application’s logic can then determine the correct database to which a connection must be made. In this way the development staff can be confident their application can be safely run on a test server with the knowledge that it will not update production data. When it comes time to deploy to the production server, the application does not have to be modified in any way and its logic will again connect to the correct production oriented database as well as being able to obtain the correct values from the application’s property file.