Archive for the ‘Tomcat Runtime Environment Variable’ Category
This post illustrates how to read the environment variable (EV) assigned to Tomcat’s JVM at the time Tomcat is started. The variable was assigned within Tomcat’s startup script to indicate Tomcat’s role as being a development server, a test server or a production server. The values were “localhost”, “TEST” or “PROD” respectively. To learn how the EV is assigned to Tomcat’s JVM select this link.
EGL does not support access to JVM variables as Java does. To solve the problem of reading the value a Java program must be employed to be called from EGL. Shown below is the Java program that reads the variable to be returned to the EGL program. Specifically the line of interest is this one:
runtimeEnvironment = System.getProperty(“runtimeEnvironment”).trim() ;
Fig.1 – The Java class ‘RuntimeEnvironment’
The strategy employed by RuntimeEnvironment is straight forward; the method getRuntimeEnvironment() reads the variable runtimeEnvironment the value of which has been assigned to the JVM. (Refer to this post to see how that was done.) In the event that a variable is not found, due mostly to the fact the developer may have elected not to assign it to their test server running on their local machine, the Java method will return “localhost” as a default value. As noted in the link which shows how to assign the values to the server, the values for “TEST” and “PROD” have already been assigned to Tomcat.
Since the Java class will need to be in all EGL projects the class has been packaged into a .jar-file so it can be reused. To use the class in your project, simply add the .jar-file to the “lib” directory under “WebContent”. Then add the .jar-file to the project’s class path. To learn how this is done select this link and read the section titled “Importing the Jar File into Your Project”.
Calling the Java method from EGL
This section describes how to create the EGL External Type and the EGL service, both of which are required when calling a Java program from EGL.
The EGL External Type Definition
First, create an external type to describe to EGL the Java class and its methods.
Fig.2 – The EGL External type named ‘RuntimeEnvironment’
The external type is an EGL part that describes an interface to another program of a different type. In this context it is the bridge between the EGL world and the Java world. The type shown above describes the Java constructor and the method named getRuntimeEnvironment() .
Calling Using a Dedicated Service
Next, create an EGL service that will use the Java class described by the external type, above.
Fig.3 – EGL service that will use the Java class
Calling the Java method from EGL
Finally, below is the EGL program code that calls the Java method to get the runtime environment variable established for Tomcat’s JVM.
The EGL function presented is part of the startup processing phase of the EGL project’s web-page. It begins by creating a dedicated service object called runtimeService which will is derived from the EGL Service program created above. Next, the EGL code calls the service’s getRuntime()method, which returns the value for Tomcat’s runtime environment variable.
Fig.4 – EGL function calling a service program
The call back function receives the variable runtimeEnvironment returned by the service call. The value of the variable is then stored in an instance of an EGL basic record called globalDataRecord In this manner the runtimeEnvironment variable can be used throughout the life of the program simply by passing the globalDataRecord as the parameter. Think of it as a container for global values.
This post has shown how to create a Java class to provide a function not available by EGL alone. Specifically, we have seen how to create an EGL External Type, an EGL Service and the code used to call the service to receive values returned.
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.
Using Tomcat’s JVM parameter values to facilitate DB connections
This post will illustrate how a database connection can be established to one of two separate iSeries machines.
Before we get going, for some background you should probably read this post first. Its is about the configuration of the server’s (Tomcat) JVM property value for run-time environment ‘localhost’, ‘TEST’ and ‘PROD’.
The application’s externally defined property values
The application’s configuration data is contained in an external XML file, a common practice in web application development. For this discussion it will suffice to say the application’s configuration data has already been read during the application’s initialization phase conducted when the application is started. During this phase the data is cached into an EGL BasicRecord type i.e. ‘configDataRecord’ which can then be passed to the application’s services as a parameter. In this manner all services can gain access to the application’s configuration data.
Shown below are the entries placed in our XML configuration file that describe connection criteria for MACH1 and MACH2 used for the developer’s (localhost) server, the test (TEST) machine and the production (PROD) machine. (User id’s and passwords are obfuscated.) Library entries, of which there is only one in this example, are separated by spaces. Note the libraries established for each machine for each development environment. In this way, each connection for each machine is assigned to the correct library ensuring the proper set of data is used for each environment. This method ensures that the developer does not have to prefix or qualify SQL statements with embedded library names, which does not translate well when moving the application from a TEST server to a PROD server.
Fig.1 – The application’s XML configuration file
Making the Connection
Shown below is the EGL code that resides in an EGL service program. The variable ‘server’, passed to the function containing this code, is used to govern which set of logic is to be executed. The value determines the values for the variables ‘machineID’, ‘userid’ and ‘password’.
Once these values are obtained the value for ‘runtimeEnvironment’ is used to obtain the correct connection string or URL. For localhost, this value will come from the XML configuration data. For TEST or PROD, the connection URL is obtained from the JNDI-defined connection criteria established in Tomcat’s context.xml file. See this post for information about that.
Fig.2 – Tomcat’s context.xml
Problem? What problem?
While everything explained so far is accurate, there is one problem, if it can be called that. It’s more of a developmental artifact than anything else and can be spotted in the configuration file. Everything will still work, but there are entries which have been rendered superfluous. Can you spot the problem? Hint: see the JNDI entries for comparison. Post your thoughts on this in the comments section below this post.
So, there we have it. We’ve seen how Tomcat configuration and the application’s externally defined property values can facilitate connections to a given database for a whole list of different machines. The value of this effort should be self-evident, that is, it does not promote hard-coded connection criteria in the application’s code which, without modifications, would prohibit deployment across multiple run time environments represented by the developer’s machine, the test or QA machine and finally the production machine.
First things, first. The server
When running Tomcat on the iSeries a few modifications to its startup script are required. First, the iSeries is headless, meaning it has no keyboard, monitor or mouse attached. (Yes, there are admin consoles, but this isn’t the same thing.)
In our case, Tomcat is running in a UNIX environment therefore the startup script for Tomcat is catalina400.sh. Do not modify the windows version (catalina400.bat)
Within catalina400.sh, Tomcat’s startup command (shown below) must be modified to include an additional parameter beyond the original parameters already supplied to the command.
Variable to indicate the server is operating in a ‘Headless’ state
The parameter “-Djava.awt.headless=true” is used to indicate to Java that the system, i.e the iSeries, is operating in a configuration in which the display device, keyboard, or mouse is lacking. See this link for a full explanation
The full command is :
All parameter name/value pairs begin with “-D”.
Without the parameter, this stack-trace is produced, which is complaining about graphics, which the iSeries does not have. This is the clue indicating the proper course of action which results in the use of the parm.