禁用JSP运行时编译后Servlet映射的JSP仍被Tomcat编译的原因

删除全局web.xml中org.apache.jasper.servlet.JspServlet相关配置，仅关闭了后缀匹配触发的JSP运行时编译链路，并没有关闭Tomcat对<jsp-file>标签声明Servlet的内置特殊处理逻辑，这就是两类访问场景表现差异的核心原因。

场景1：直接访问JSP路径不触发编译的逻辑 #

• 默认配置下，Tomcat全局web.xml为JspServlet配置了*.jsp、*.jspx的URL匹配规则，所有后缀匹配的请求都会转交JspServlet处理，由其完成JSP到Servlet的翻译、编译、执行全流程。
• 移除JspServlet配置后，没有Servlet组件负责处理.jsp后缀的请求，Tomcat会将匹配到的JSP文件视为普通静态资源，直接读取文件原始内容返回，因此访问时会直接展示JSP源码，不会触发编译。

场景2：配置的映射路径触发编译的逻辑 #

• Tomcat解析应用web.xml时，只要识别到<servlet>节点下存在<jsp-file>子标签，就会将该Servlet标记为JSP类型Servlet，该处理逻辑是Tomcat容器的内置核心逻辑，完全不依赖全局注册的JspServlet组件。
• 当该标记为JSP类型的Servlet第一次接收请求时，Tomcat会自动调用内置的Jasper编译器，将<jsp-file>指向的JSP文件翻译为Java Servlet源码、编译为字节码、加载到容器后执行请求逻辑，你配置的<url-pattern>只是给这个动态生成的Servlet绑定了自定义访问路径，和请求后缀是否为.jsp无关。
• 该逻辑的触发点是web.xml加载阶段对<jsp-file>标签的识别，因此哪怕你把访问路径配置为/myjsp这类不带.jsp后缀的路径，依然会触发JSP的编译执行。

快速验证方法 #

你可以通过两个简单配置验证上述逻辑：

1. 将场景2配置中的<jsp-file>替换为普通<servlet-class>配置，保留原有/myjsp路径映射，访问时不会触发任何JSP编译逻辑。
2. 恢复全局JspServlet配置后，给JSP配置<jsp-file>映射到非.jsp后缀的路径，此时直接访问JSP原路径会走JspServlet链路编译，访问自定义映射路径会走<jsp-file>的内置处理链路编译，二者是完全独立的两条处理流程。

内容的提问来源于stack exchange，提问作者Hari Prasandh