Remy Maucherat wrote:
Jan Luehe wrote:
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?
I think it would, I agree it would be a nice feature. Or even if the JSP does exist, but the developer prefers to precompile JSPs in order to eliminate the initial compilation lag.
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.
Would it look in WEB-INF/classes for the servlet class files, or in tempdir ? Currently JspServlet looks in tempdir, but the precompiled classes are stored in WEB-INF/classes (by appendix A of the JSP spec).
Loading the servlet from WEB-INF/classes may have the problem that classes from this place are loaded by the WebApp's classloaders, so they will not bubble up to JasperLoader, which may result in problems with reloading JSPs (without redeploying the whole app). Won't this be a problem?
In SunONE Studio, we provide our own JspServlet, which has a somewhat modified reloading logic for JSPs. In addition to checking whether the JSP is newer than the class (in which case it recompiles and reloads the page), it also checks whether the class was modified since the page was last loaded (even if class timestamp > JSP timestamp), and if it is, it reloads the page without recompiling it.
This will eliminate the need for adding servlet mappings for precompiled JSPs to the web.xml.
I think this is a good goal.
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.
Another advantage is that it would allow having a more lightweitght classloading mechanism for precompiled pages, which would also support lightweight JSP reloading.
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).
Remy, I agree that it would be useful to have this in the spec. In fact, Ana (in cc:) has already brought this up with Mark Roth.
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).
I think that JspServlet is a better place to implement this. The only thing you'd need to change is the reloading logic, and possibly address any classloading issues.
-1, I completely disagree with this. You're simply adding a hack to provide a useless feature. Either the JSP in compiled and it is a servlet (and handled as a servlet, with the same constraints and benefits), or it is a JSP page which is loaded in its custom classloader. Adding more complexity in the lame duck warpper (aka JspServlet) is *bad*.
You're trying to use precompilation in a way it is not designed for.
Note: Unless the feature is mandated in the spec (optional isn't enough), I will veto it.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
