On Java Development

All things related to Java development, from the perspective of a caveman.

Startup Servlet

without comments


This post is about using a servlet to perform the initialization of a web application. In an RPG program this would be performed using *INZSR but for web applications a servlet is used. This approach allows tasks to be performed only when the server starts. Since the servlet is part of the application the tasks performed are tailored for it alone.

Making the Application Ready
Like RPG programs, web applications have certain activities which need to be performed before the application is deemed ready for use. For example, Spring will be initialized during the application’s startup phase. Shown below is the list of tasks being performed by the web-application’s startup process.

  1. Obtain the value for $CATALINA_HOME
  2. Obtain the value for “runtimeEnvironment”
  3. Obtain today’s date to be inserted into the application’s log file name
  4. Implicitly initialize Spring’s context to contain the beans defined
  5. Use Spring to read the application’s property values that are considered global in nature
  6. Use Spring to read the application’s property values that are specific to a runtime environment
  7. When running on the developer’s machine set the developer defined log-file path
  8. Initialize Log4J and log information obtained during this processing

The thing is, for web applications there isn’t a subroutine like *INZSR that can simply be called at the beginning of every program. There is however, a configuration technique that is often employed for such one-time-only tasks. It insures that when the server starts each application’s designated serlvet starts to perform the required work. Because the work is performed when the server starts, the first user of the application doesn’t have to wait for that processing to complete before getting to see the first page.

The Startup what?
Simply put, servlets are described as “small, server-resident programs that typically run automatically in response to user input.”

The servlet container, that is, the server, can evoke named servlets during certain run time phases without having to rely upon user interaction. Using certain configuration entries this ability will be used to run initialization tasks for each application.

Configuring Tomcat
Every web application has what is known as a deployment descriptor.

A deployment descriptor refers to a configuration file for an artifact that is deployed to some container/engine. In the Java Platform, Enterprise Edition, a deployment descriptor describes how a component, module or application should be deployed.

Entries have to be added in the project’s deployment descriptor file called web.xml. Every application has one of these files. Entries can be made to this file to ensure that a certain servlet is called when the server starts in the mornings. Because of the configuration entries used, once completed it will not perform the tasks again until the server is again started.

Shown below is the servlet definition with the all-important “load-on-startup” priority of “1”. “load-on-startup” is where Startup Servlet gets its name, but more importantly the value assigned to this tag tells the server that among the application’s servlets to be loaded during the server’s startup phase, this will be the first. If there are no others configured in this manner, then this represents the only servlet started for the application. All others will start as a consequence of a user’s interaction with a browser.

Startup Servlet
Shown below is the code for Startup Servlet. The tasks performed were outlined at the beginning of this post so going over them again isn’t necessary. This servlet is included in baseproject. Modifications are not required and it is ready to use as-is.

Reading and Caching Application Property Files
Some of the tasks performed by the startup servlet require the use of externally defined configuration or property files. These can take on different forms. The first is a simple text file containing name/value pairs and defined as shown.

  • emailFeatureOn=true
  • dbServerIP=the.server.com
  • userID=dbUser
  • password=password

The second is to use XML to define each name/value pair.

The first two presented above rely upon customized Java classes to be written to read the property files and to parse out each name/value pair which are then stored within lists contained by other Java class files. The classes containing the property values must then be made accessable across the application so that it can read the name/value pairs whenever needed. This code must then be repeated across all applications for their properties. The Java code for this varies for each developer responsible for its design but once developed it can be adopted across all applications within the organization.

When using Spring, the properties are often defined within XML files. For example:

The values are read when Spring is initialized and then placed into Java class files. This allows the application to read the values whenever needed.

The main difference between the first two approaches and Spring’s approach is that Spring provides the architecture to read this file and means the Java architect does not have to design, write and debug the code that reads and parses this file. In addition, the Java classes responsible for caching the Java class files holding these values does not have to be developed and then debugged. Spring contains this architecture and is is readily reusable across all application that incorporate Spring’s libraries. Further, the developer has access to Spring’s documentation so that they can turn to that documentation to learn more about this mechanism.

When obtaining third party software that also use Spring, the organization is immediately familiar and the learning curve is minimized.

Written by admin

January 18th, 2014 at 6:47 pm

Leave a Reply

You must be logged in to post a comment.