i have one doubt regrading the JSP program execution.
i.e when i change/modify the jsp the page the tomcat is not restarted, but the output is reflected.
where as same thing if i have make changes with the servlet program then it will not reflect until server is restarted.
even jsp also generated the java code first and then starts executing.
may i know why we have such difference between JSP and Sevlets java programs.
Then, provided your application is declared as reloadable in Tomcat's server.xml, it should cause a refresh in any modifications to servlets as well as JSPs (which are just servlets). I'm not actually sure how it does this (if anyone knows, please say), but I would imagine it makes clever use of ClassLoaders to allow classes within an application to be swapped in and out of service?
If your Tomcat isn't doing this, first make sure it definitely is Tomcat at fault (e.g. that you didn't actually forget to upload the new class files, which has happened to me before!), then check your Tomcat version and check the bug database, and finally upgrade your Tomcat if possible. It should be working - although personally I prefer to keep auto-reload off and restart manually. It increases performance.
Any further thoughts on this one welcome!
Servlets are loaded by the web class loader, and it loads the servlet classes once.
JSPs are loaded by JSP classloader. Some implementations may have one class loader for each JSP, whereas others might have single class loader for all the JSPs.
1. When a JSP is changed, the JSP container recompiles the JSP page.
2. It throws away the JSP class loader that was used to load the old version of JSP class.
3. It creates a new class loader with the webapp class loader as parent and serves the page.
This is incorrect: I know from experience that redeploying a servlet class on my Tomcat 5.0.x installation causes that servlet to auto-reload... since I dislike this (and am always concerned this won't work correctly), I prefer to disable auto-reload, but this should still work. If you don't believe me, consult Tomcat server.xml configuration for <context>:
From previous post:Servlets are loaded by the web class loader, and it loads the servlet classes once.
Look under the "reloadable" attribute and you'll find this comment:
So note that Tomcat specifically says it will reload classes in the classes/ and lib/ directories and will reload the web application - it says nothing about reloading individual components or indeed having multiple ClassLoaders per application... in fact it implies otherwise.
From Tomcat Configuration:Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected.
I suppose this will depend on the implementation used, but I think Tomcat reserves only one class loader for each Web application (or at best only one per application for JSPs and one for other classes and servlets).
From previous post:JSPs are loaded by JSP classloader. Some implementations may have one class loader for each JSP, whereas others might have single class loader for all the JSPs.
Where did you get your information from - was it a book, specification, article, reference guide? I'd be interested to find out more and I would find it useful to implement such dynamic swapping of classes myself, so if you know of any material on using ClassLoaders in this way, please say.
[ May 15, 2006: Message edited by: Charles Lyons ]
How JSPs classes are loaded
A JSP class can be configured to be loaded by either the JSP engine's classloader or by the Web module's classloader.
By default, a JSP class is loaded by an instance of the JSP engine's classloader, which enables run time reloading of a JSP class when the JSP source or, optionally, one of its dependents, is modified. By default, each JSP is loaded by a unique instance of the JSP engine's classloader. This allows a single JSP class to be reloaded when necessary, without affecting any other loaded JSP classes.
JSP classes will be loaded by the Web module's classloader under either of the following scenarios:
The JSP engine configuration parameter useFullPackageNames is set to true, and the JSP is configured as a servlet in web.xml using the <servlet-class> scenario in Table 2.
The JSP engine configuration parameters useFullPackageNames and disableJspRuntimeCompilation are both set to true. A JSP does not need to be configured as a servlet in web.xml in this case.
Configuring JSPs as servlets
A JSP can be configured as a servlet in web.xml. There are two ways to do this, described below in Table 3. Before configuring a JSP as a servlet, though, consider the following:
If run time reloading of JSPs is required, requests for JSPs must be handled by the JSP engine. The <servlet-class> scenario in Table 3 would disable run time JSP reloading, while the <jsp-file> scenario would be compatible with reloading.
Reducing the number of classloaders
If run time reloading of modified JSPs is not required, and if limiting the number of classloader instances is desired, then the <servlet-class> scenario in Table 3 can be used. Similarly, scenario B in the previous section can be used without having to configure a JSP as a servlet.