由 webmaster 发布于: 2001-01-30 09:22

It depends on the web server you are using to test your servlet. For instance, with Tomcat, you would replace the WAR file and the server notices the change and loads the new servlet on the next request, without having to restart the server.
[Note that there is a bug in Tomcat where replacing the WAR file doesn't work; you also have to delete the unpacked directory under TOMCAT/webapps/foo (for TOMCAT/webapps/foo.war).

If you are not using WAR file deployment, simply replacing the servlet classfile should work, as long as the class file is stored in webapp/WEB-INF/classes, or replacing the JAR file in webapp/WEB-INF/lib/foo.jar.

由 webmaster 发布于: 2001-01-30 09:24

There is no standard method/mechanism to unload a servlet from memory. Some servers, like JWS, provide the means to load and unload servlets from their administration module.

由 webmaster 发布于: 2001-01-30 10:56

Automatic reloading of servlets by a servlet container comes in handy during the development phase when you are frequently modifying and recompiling the servlets. Having to constantly shutdown and restart the servlet container each time you modify a servlet class can become tiring very quickly.

Automatic reloading of servlets in Tomcat 3.1 is predicated upon two entries in two different files in the directory TOMCAT_HOME/conf:

1。In the file TOMCAT_HOME/conf/server.xml, you must set the reloadable attribute to true in the context element pertaining to your webapp. For example, I have a webapp named form-processing. So I added the following entry to the file TOMCAT_HOME/conf/server.xml:

<Context path="/form-processing" docBase="webapps/form-processing"
debug="0" reloadable="true" >
</Context>


2。The file TOMCAT_HOME/conf/tomcat.properties allows you to specify a classpath that is passed on to the JVM. The servlets that you want automatically reloaded must not be in this classpath. Note that this classpath is in addition to the classpath specified in the startup file tomcat.bat in the directory TOMCAT_HOME/bin. For the simple webapp form-processing that I mentioned above, I do not need to specify any additional classpaths in the TOMCAT_HOME/conf/tomcat.properties file.

For those just getting into Tomcat 3.1, I should add the caveat mentioned in the Tomcat readme file that the automatic reload feature in Tomcat 3.1 is not recommended for production applications. At this time, it is an experimental feature that when enabled creates extra overhead in processing servlet requests.

由 webmaster 发布于: 2001-01-30 10:58

A ClassCastException usually means that you've changed a *support class* rather than changing a *servlet*. The latter is supported, the former is not.

What's happening is, Tomcat has special support for making a new instance of a reloaded servlet class, and forwarding new requests to that servlet. But it can't do the same for object instances that are already in memory. So if you have, say, an instance of FooBean stored in a session, then change the class FooBean, then there will be two versions of the class FooBean in the JVM. The object is class FooBean(1), which cannot be cast to a FooBean(2) (since they're two totally different classes with the same name).

This points out a serious (IMHO) flaw in the Java Language itself. Java has no facilities for cleanly unloading or reloading classes. But without this ability, it becomes impossible to use Java to support a long-running service, like a web server or an operating system. But the solution is non-trivial, so it's no wonder they haven't fixed this yet.