tomcat-dev mailing list archives

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


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

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

View raw message