OpenVMS Notes: Apache Tomcat

Table of Contents

Apache Tomcat, Java, etc.

Apache Tomcat is a standalone Jakarta product used to serve up Java generated content on port 8080 (by default). It is also able to serve-up HTML so it is also correct to think of Tomcat as a webserver written in Java.

Simplified Component Overview:

  1. Apache HTTPd is an HTML web server that usually listens on port 80 (raw) or port 443 (SSL encrypted)
  2. Apache Tomcat is a standalone Jakarta product used to serve up Java generated content on port 8080 (by default). It is also able to serve-up HTML so it is also correct to think of Tomcat as a webserver written in Java.
  3. Connectors are used to provide an internal communications channel between Apache HTTPd and Apache Tomcat. These connectors allow Apache HTTPd to divert what contains (based upon file extension) server-side Java via port 80 (or 443) over to Apache Tomcat. Don't waste time fooling around with connectors until you get the Tomcat server working properly on port 8080. In fact, don't waste your time on this until you are preparing to move something into production.

Product Name Confusion (re: OpenVMS)

Product Description/Notes
ANT Another Neat Tool (an Apache script interpreter)
Apache HTTPd Hyper Text Transport Protocol daemon is a standalone product which operates on TCP/IP ports 80 (http) and 443 (https) by default. When OpenVMS was owned by Compaq, this product was called CSWS (Compaq Secure Web Sever) pronounced "C-Swiss". Since HP bought (err, merged with) Compaq, I have heard HP engineers refer to this product as "Swiss" but the downloadable modules still have a "CSWS" prefix.
CSWS_JAVA HPE's name for Apache Tomcat (requires Java which is not included)
CSWS_PERL HPE's name for a module which enables Apache HTTPd to access Perl (requires Perl)
CSWS_PHP HPE's name of a module which provides Apache HTTPd with a PHP Interpreter
Apache Tomcat A standalone Java-based web server product which operates on TCP/IP port 8080 by default
(configure the connector kit to facilitate back channels between HTTPd and Tomcat)
Confusingly, the Compaq/HP Tomcat product for OpenVMS is named CSWS_JAVA
Jakarta Apache's umbrella name for Java projects
Catalina Name of Tomcat's Servlet Container Technology
Coyote Tomcat's Java-based HTTPd server
Jasper Tomcat's JSP technology
GNV GNU Not VMS (Unix command interpreter for OpenVMS which includes BASH)
Java Standalone product required by Tomcat. You want the development kit (because of the JIT compiler), not the run-time)
1.5 and higher 1.4 and lower
JDK java development kit SDK standard development kit
JRE java runtime edition RTE run time edition
JAVA 5 comes up as version 1.5
JAVA 6 comes up as version 1.6
JAVA 8 comes up as version 1.8
OpenSSL Open Secure Sockets Layer "standalone product" (not used by Apache HTTPd which has its own built-in OpenSSL routines)
Question: So why would you ever use it? Answer: to support encryption in client apps or standalone server apps
Required by OpenVMS 8.x (used to validate HP patch kits)
Perl Standalone product (required by CSWS_PERL)
SOAP Toolkit 1.1 SOAP 1.0 - based upon Apache SOAP 2.31 - Apache's proof of concept SOAP offering (now obsolete)
SOAP Toolkit 2.0 SOAP 1.1 - based upon Apache AXIS/Java - Apache's first production SOAP engine (now obsolete)
AXIS2 SOAP 1.2 - based upon Apache AXIS2/Java - Apache's second production SOAP engine (served up by Tomcat)
WSIT Web Services Integration Toolkit (technology for accessing high level language routines from Java-based web services)
UDDI Universal Description Discovery and Integration is another Web Services component
(this technology has not lived up to original expectations)
gSOAP generated SOAP. Third-party SOAP engine supporting SOAP code based upon C/C++
(this looks like a very promising alternative to AXIS2/c which is not available on OpenVMS unless you are willing to do your own build from Apache sources)

Java vs. JavaScript

  1. JavaScript (originally called "LiveScript") is an interpreted "object aware" (although some say "object oriented") scripting language co-invented by Netscape and Sun Microsystems. The code (almost always) runs in a your browser and is visible when you select "view source" under your browser's FILE menu.
  2. Java is a compiled "object oriented" language invented my Sun Microsystems. The Java compiler produces bytecode (not machine code) which can run on any computer provided a Java Virtual Machine (JVM) is installed on that target machine.

    • Java Applets are written in Java then compiled. The resulting bytecode .CLASS file is run in your browser via calls to your JVM.
    • Java Servlets are written in Java then compiled. The resulting bytecode .CLASS file is run for you by the web server (using the server's JVM) and the results are displayed in your browser.
    • Java Scriptlets are written in a combination of Java and HTML then saved as .JSP files on your web server. When first run, they are converted to .JAVA (Java source code) then a just-in-time (JIT) Java compiler is invoked to generate a .CLASS file which is then run for you on the server's JVM. This "first time" conversion process is not repeated unless the server notices that the date stamp of the requested .JSP file is later than the date stamp of the associated .CLASS file.
       
  3. Except for the first 4 characters of their names, Java and JavaScript have very little in common.

Installing Java and Apache Tomcat on OpenVMS Alpha (circa 2010)

Small Machine Caveat

Interpreted and semi-interpreted technologies like Java and SQL can take their toll on a server's computing power so don't expect much when running Tomcat on RISC (Alpha) machines manufactured in the middle 1990s. CISC (VAX) machines aren't even supported.

  Java Performance
best average low
system speed Above 500MHz 500 MHz Below 500MHz
system memory 1GB or higher 500 MB Minimum 256MB

I initially experimented with Tomcat on a discarded AlphaServer-2100 only to discover that the Tomcat server can take between 1-2 minutes to initialize (this link will help reduce this). Also, invoking a previously uncompiled "Java Scriptlet" might take up to 30 seconds before output is returned to the browser (but what would you expect from a computer built in 1994 with a 275 MHz clock, 128-MB of memory and no L2 cache?). This link suggests we shouldn't even attempt to install Tomcat on a machine this small. This same operations ran much faster on an AlphaServer-DS20e with two CPUs and 1 GB of RAM.

Installing Java

  1. You must install Java for OpenVMS before attempting to use Tomcat. Don't waste your time installing the run time edition (RTE or JRE). Instead you should install the full software development kit (SDK or JDK). Why? Many of the Tomcat files are supplied in .JSP form and so need to be compiled before use. Tomcat will do this for you on an as-needed basis provided a JAVA compiler is available
     
    • Java versions 131 to 141 should be installed into SYS$COMMON because certain scripts (like the Tomcat configuration script "SYS$STARTUP:APACHE$JAKARTA_CONFIG.COM") use that directory to test for the presence of JAVA on your system.
       
    • Java versions 142 to 160 can be installed anywhere with the latest version of Apache Tomcat (5.5.26 which comes with CSWS_JAVA 3.1)
       
    • You may find this document: JAVA FAQ on Alpha useful for clearing up some points for using JAVA with Alpha or Itanium. Also be sure to read this document: Optimizing Java™ Technology Software Performance on HP OpenVMS

Installing Tomcat

  1. Next you must install CSWS_JAVA which contains the Tomcat server as well as the connector kit (mod_jk, mod_dk2, mod_webapp)

    • Be sure to run script SYS$STARTUP:APACHE$JAKARTA_CONFIG.COM to set the Apache user name (mine is set to "APACHE$WWW").
       
      Caveats:
      • If you are using a VT compliant terminal emulator then make sure the half-dozen lines above your menu do not contain any error messages like "Can't Find Java". If you see this then you may need to tweak the script so it will be able to locate your version of Java. Why?
        • Sometimes this script is capable of supporting older versions of Java except for the fact that the old code is disabled
        • Sometimes a new Java kit is released before the Tomcat scripts are updated (this happen to me with while using CSWS_JAVA 3.0 with Java 142).
           
  2. Once set up, test the Tomcat server by pointing a browser to port 8080 like so:
     
        http://www.your-host.net:8080
     
  3. Run script SYS$STARTUP:APACHE$JAKARTA_CONFIG.COM again and add connector support to Apache. I used "mod_jk2" due to some suggestions from the net.

    • connector "mod_jk" utilizes control file "workers.properties"
    • connector "mod_jk2" utilizes control file "workers2.propoerties"
    • connector "mod_webapp" utilizes control file "mod_webapp.conf"

    Note that "APACHE$JAKARTA_CONFIG.COM" places a copy of the desired control file in [.conf] for easy access
     
  4. Modify the appropriate worker's file to modify Apache's mapping.

  5. Restart Apache HTTPd so the appropriate module (e.g.. mod_?) is loaded along with its connector control file.
  6. Create a Java Scriptlet (in one of the mapped directories) with the name HelloWorld.jsp. The file should contain the following: 
    <html>
<body>
<%
out.println("<h1>Hello World!</h1>");
%>
</body>
</html>
  7. Now request that file on port 80 like so:

        http://www.your-host.net/jsp-demos/HelloWorld.jsp
    • If everything works properly, Apache will send the request to Tomcat via the connector.
    • Tomcat will look to see if it has an up-to-date compiled version of this script.
      • If it doesn't, it will invoke a translator to produce "HelloWorld.java" which will then be compiled to HelloWorld.class
    • Tomcat with run HelloWorld.class through the JVM (Java Virtual Machine) and the results sent back to Apache via the connector.

Installing Java and Apache Tomcat on OpenVMS Itanium (circa 2018)

This might never be used in production but we need to develop some client-side tools for accessing a remote service which is not yet available. This will be our mock destination until we are ready for end-to-end testing with the remote system.

Itanium install: 2018-01-05

Links:

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.