Currently, if webapp developers do not want to expose the source of their JSP files, they have to precompile them and add a servlet mapping for each JSP to their web.xml (e.g., with the help of jspc).
If the webapp contains a large number of JSPs, the web.xml is going to grow pretty big.
Would it make sense to have Jasper try to load a class file corresponding to a JSP, even if the webapp does not have the JSP source file and does not specify any servlet mapping for that JSP?
So if someone accesses a JSP for which there is no servlet mapping, the JspServlet will first determine if the JSP exists, and if it doesn't, it will try to load the corresponding class file. If the class file does not exist, a 404 is returned.
This will eliminate the need for adding servlet mappings for precompiled JSPs to the web.xml.
One advantage of having the servlet mappings is that precompiled JSPs may be selectively exposed, whereas with the proposed scheme, *any* precompiled JSP would be exposed. We could define a config option in JspServlet that would disable the proposed behaviour and require a servlet mapping in order for a precompiled JSP to be exposed.
Comments?
-0. A compiled JSP is a servlet, and tools exist to automate the inclusion in web.xml (please have a look at the tomcat-deployer package; I belive it can't get much easier). Its size is irrelevant IMO (if you want it to be smaller, you should look into improving the specification instead).
For doing the same thing with regular servlet, we had the InvokerServlet, and look at how much security issues we did run into because of it.
If you'd really like to implement your feature, you could add a "JSP mode" to the InvokerServlet, as there's much functionality in common (and the InvokerServlet creates real Catalina wrappers, with complete stats, etc, like if it had a web.xml mapping).
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
