When a server dispatches a request to a
When a server dispatches a request to a servlet, it first checks if the servlet’s class file has changed on disk. If it has changed, the server abandons the class loader used to load the old version and creates a new instance of the custom class loader to load the new version. Old servlet versions can stay in memory indefinitely (and, in fact, other classes can still hold references to the old servlet instances, causing odd side effects, as explained in Chapter 11, Interservlet Communication), but the old versions are not used to handle any more requests. Servlet reloading is not performed for classes found in the server’s classpath (such as server_root/classes) because those classes are loaded by the core, primordial class loader. These classes are loaded once and retained in memory even when their class files change. It’s generally best to put servlet support classes (such as the utility classes in com.orielly.servlet) somewhere in the server’s classpath (such as server_root/classes) where they don’t get reloaded. The reason is that support classes are not nicely reloaded like servlets. A support class, placed in the default servlets directory and accessed by a servlet, is loaded by the same class loader instance that loaded the servlet. It doesn’t get its own class loader instance. Consequently, if the support class is recompiled but the servlet referring to it isn’t, nothing happens. The server checks only the timestamp on servlet class files.* A frequently used trick to improve performance is to place servlets in the default servlet directory during development and move them to the server’s classpath for deployment. Having them out of the default directory eliminates the needless timestamp comparison for each request. * For the daredevils out there, here’s a stunt you can try to force a support class reload. Put the support class in the servlet directory. Then convince the server it needs to reload the servlet that uses the support class (recompile it or use the Unix utility touch). The class loader that reloads the servlet should also load the new version of the support class. Init and Destroy Just like applets, servlets can define init()and destroy()methods. A servlet’s init(ServletConfig)method is called by the server immediately after the server constructs the servlet’s instance. Depending on the server and its configuration, this can be at any of these times: When the server starts When the servlet is first requested, just before the service()method is invoked At the request of the server administrator In any case, init()is guaranteed to be called before the servlet handles its first request. The init()method is typically used to perform servlet initialization creating or loading objects that are used by the servlet in the handling of its requests. Why not use a constructor instead? Well, in JDK 1.0 (for which servlets were originally written), constructors for dynamically loaded Java classes (such as servlets) couldn’t accept arguments. So, in order to provide a new servlet any information about itself and its environment, a server had to call a servlet’s init()method and pass along an object that implements the ServletConfiginterface. Also, Java doesn’t allow interfaces to declare constructors. This means that the javax.servlet.Servletinterface cannot declare a constructor that accepts a ServletConfigparameter. It has to declare another method, like init(). It’s still possible, of course, for you to define constructors for your servlets, but in the constructor you don’t have access to the ServletConfigobject or the ability to throw a ServletException.
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services