There is a script called JSPC in the bin directory of Tomcat4. It is just running the translation phase, not the compile stage, using it to generate a Java source file in the current directory. It is a powerful means of debugging the JSP page.
You can access the result of the compilation through the browser. This ensures that the file is converted to a Serverlet, which is compiled. This also accurately imitates the real user to access the JSP page, and you can see the features provided to the user. Also grab this last minute to modify the bug and modify it J
Tomcat provides a feature that compiles the JSP page by request. For example, you can enter in the browser address bar
http: // localhost: 8080 / example.jsp? jsp_precompile = true, so tomcat will compile DATA.JSP instead of executing it. This is a shortcut to the correctness of the test page.
4. Others
We mentioned before
The operating system prevents malicious service attacks through some restrictions, and the same Tomcat also provides settings to prevent malicious attacks or ban some machine access.
Tomcat offers two parameters for you to configure: RemotehostValve and RemoteAdddrvalve.
By configuring these two parameters, you can filter from the requested host or IP address and allow or reject which host / IP. Similarly, there is a permission / rejection specified for each directory in the HTTPD file in Apache.
For example, you can set the Admin Web Application to allow local access, set as follows:
If you do not give the host's designation, the host that does not match the host will be rejected, which is allowed to be allowed. Similarly, if the designation of the reject host is not given, the host that is allowed to match the host will be allowed, in addition to the rejection.
V. Capacity Plan
The capacity plan is another important topic that use Tomcat to improve performance in the production environment. If you don't think about the hardware and bandwidth of the expected network traffic, then no matter how you do configure and modify and test it.
Here, the capacity plan mentioned here is a brief definition: the capacity plan refers to an event that evaluates hardware, operating system, and network bandwidth, determining application services, seeking a software that is suitable for demand and software characteristics. Therefore, the software mentioned here includes not only Tomcat, but also any third party web server software used in conjunction with Tomcat.
If you don't know if you purchase a hardware and hardware or deploy system, you don't know how much your access is supported, even worse, you have delivered and deploy it in the production environment.
After the product, I realized that there is a problem when there is a problem, it may be too late. At this point, you can only increase hardware input, add hard disk capacity and even buy better servers. If you do a capacity in advance, you will not make such a focus.
We only introduce the content related to Tomcat here.
First, in order to determine Tomcat's capacity plan, you should use the list of items to study and plan:
Hardware
What kind of hardware system uses? How many computers needed? Use a large or multiple small machines? How many CPUs are used on each computer? How much memory is used? What kind of storage device is used, what is the requirements for I / O processing speed? How to maintain these computers? How different JVMs run on these hardware (such as IBM AIX systems can only run on their hardware systems)? 2. Network bandwidth
How much is the bandwidth usage limit? How do Web applications handle too much request?
3. Server operating system
Which operating system is the best? Which JVM is used on the determined operating system? For example, whether the JVM supports local multi-threads on this system, symmetrical multi-processing? Which system allows web servers faster, more stable, and cheaper. Do you support multi-CPU?
