Servlet Reloading

Servlet reloading was introduced because, starting with TINI firmware 1.10, dynamic classloading became possible. In the Tynamo™ server, it is possible to turn this feature on or off, and even to exclude it from the web server binary.

Some definitions are necessary:

Servlet Reloading
In this document, this refers to the mechanism used to load and reload servlets except when they are loaded with the special Loader Servlet.
Loader Servlet
This is a special servlet, optionally included in the build, that can load and reload servlets without specifying them in the servlet configuration file.

Subject Menu

Building Reloading into the Binary

There are two build properties, include.servletReloading and include.loaderServlet, that control how the build process incorporates support for servlet reloading. Reloading is not possible if this support is not built into the binary.

Because a dynamically loaded class may reference any member from the Servlet API, it is necessary to include much more reflection information and some support classes. This has the effect of increasing the size of the binary by approximately 8k. Other than classloading speed, this is the only deterministic disadvantage of including reloading support in your server.


Servlet Configuration

All servlets, including dynamically loaded servlets not loaded by the special Loader Servlet, must be specified in your servlet configuration file. The server cannot find your servlet if it is not declared here.

In other words, declare your servlets as normal in the servlets.props file.


The Servlet Classpath

The reloading mechanism first looks for classes in the default and user classpaths, and then in the paths specified by the servlet.classpath configuration property.

[Motivation: The user and default classpaths are specified with the '-classpath' and '-bootclasspath' options when starting a program with the 'java' command in Slush. For example (note that the line may be wrapped, but should be on one line):

java -classpath /myclasses:/web/classes webserver.tini /web/bin/webserver.props &

In this case, /myclasses and /web/classes will be searched first by the system classloader, and the paths specified in servlet.classpath will be searched next. Classes loaded by the system classloader cannot be reloaded, and that is the reason for having this extra configuration property. ]

In other words, don't use the '-classpath' option for your classes.

Note that the Loader Servlet does not use this property, and has its own classpath mechanism.


Servlet Reloading Internals You Need to Know About

Even with servlet reloading capabilities built into the binary, it is still possible to turn this feature off with the servlet.reloadingEnabled configuration property. With this value set to false, the servlet container will not search for new classes.

Second, there is a property called servlet.maxTimeBeforeDestroy that controls the maximum amount of time the container spends waiting for uncompleted service calls on a servlet. After this time has elapsed, the servlet is destroyed regardless. While the default value for this property is 20 seconds, the safest is probably an indefinite wait time, indicated by a value of 0 seconds.

To quote from Section 3.3.4 of the servlet 2.2 specification, "End of Service":

"Before the servlet container can call the destroy method, it must allow any threads that are currently running in the service method of the servlet to either complete, or exceed a server defined time limit, before the container can proceed with calling the destroy method."

Third, if a servlet was dynamically loaded and its classfile disappears, then the container will reuse the one it has already loaded. If this is undesirable behaviour, please let us know.


The Loader Servlet

The "Loader Servlet" is a special servlet included with the distribution that can load servlets, given only the classname. It searches the path specified by an initialization parameter. For example:


For the above specification, the servlet will search the default and user classpaths, and then /web/servlet/classes for a given classname. Notice how the search classpath is specified. It is a servlet initialization parameter named "classpath".

Further details about the "/*" at the end of the mapping can be found in the Servlet 2.2 Specification, but in short, it allows extra information to be passed to the servlet in the form of a path. This is called the "Path Info" part of the request.

[Motivation: The Path Info specifies the classname of the servlet to load, and any parameters are passed to the servlet as normal. This is the motivation for using the Path Info for the servlet. It allows the parameters to be passed untouched.

For example, if we use the above mapping, this request (note that the line may be wrapped, but should be on one line):


will call the com.qindesign.servlet.example.RequestInfoServlet servlet with param1 and param2 as parameters. ]

Lastly, for each requested servlet, a new instance is always created, and the servlet goes through its entire lifecycle, from init to destroy.



In summary, here are the things you need to do to take advantage of the Tynamo™ server's servlet reloading capabilities:

  1. Include this feature in the binary using the include.servletReloading property of the build properties file.
  2. Ensure reloading is turned on via a value of true for the servlet.reloadingEnabled configuration property.
  3. Take care that your servlets are mentioned in the servlet configuration file.
  4. Specify the location of your classes in the servlet.classpath property.

To take advantage of the Loader Servlet, follow these steps:

  1. Include this feature in the binary using the include.loaderServlet property of the build properties file.
  2. Properly configure the Loader Servlet in the servlet configuration file.