tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Date Thu, 24 Jul 2003 11:16:21 GMT
Petr Jiricka wrote:
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message