在说明问题之前，首先要介绍一下tomcat的工作原理。大家都知道，jsp可以说是servlet的一种简单写法，它本质还是一个servlet，只是将一些servlet对象设为默认对象，并简化了HTML的输出方式，在运行时，相应请求的机制和servlet基本是一个道理。
因此，当第一次请求一个jsp页面的时候，tomcat（或其他容器）都要首先将jsp转化为servlet class。这其中有两个步骤，首先，调用jsp解析器（如jspc）将jsp文件变为java源文件。其次，调用编译器，将转化后的java文件编译成类文件。这两个步骤都需要大量的cpu和内存资源，相当缓慢。这就是jsp初次运行慢的原因所在。
这里有一个问题，即“第一次请求”是什么意思？其实，tomcat编译jsp后，将.java和.class文件都存到了work目录里，当请求一个jsp页面时，它会去查找，如果没有或者以前的.java文件比服务器上的.jsp文件旧（根据文件日期），就重新解析，自然也要重新编译。而且tomcat默认是不删除生成的.java和.class的，即使你停掉tomcat再启动，只要jsp文件没更新，那就会使用原来生成.class文件。
OK，明确了上述原理，那么IDEA中的tomcat插件有什么问题呢？不知大家有没有觉得在IDEA中启动web-module非常的慢，至少比JB要慢好几倍。原因就是：IDEA启动Tomcat时将删除work目录的所有内容！因此，不管你是否曾经运行过tomcat，不管你的jsp是不是早就编译过了。只要你通过IDEA启动一次tomcat，你所有的JSP只要一打开，都肯定要重新编译。可能有的人没发觉，但是如果你的首页包含多个引用页面或者struts的tile页面，那么这个过程可能会慢的让你无法忍受。更郁闷的是，你可能会经过很多这种过程才能够进入你想要调试的页面。另外，用IDEA启动的tomcat4.0是无法使用manager来reload的（这个问题也可以解决），如果你修改了某个类又不能reload changed classes的时候，你只能关闭当前运行的tomcat，然后再启动，再经历一番等待，才能看到效果。机器不好的话，你可能会有搬起椅子往前甩的冲动哦。
好了，说了这么多，解决方法呢？很简单，把plugins的tomcatIntegration/lib里的jar文件反编译，去掉相应的删除代码就可以了。具体的代码阅读过程先略，有时间再写。文件位于http://www.jroller.com/resources/WarBaby/tomcatintegration.jar中，下载后替换原来的plugins/tomcatIntegration/lib/中的即可。修改的内容：1、不删除IDEA安装路径/system/tomcat临时目录/work中的内容。2、不会删除原来的web应用程序的<Context>定义，这样就可以正常使用tomcat4.0的manager应用了。
本文地址：http://com.8s8s.com/it/it14095.htm