Archive for the ‘Tomcat on iSeries’ 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.
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.