You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jan Luehe <Ja...@Sun.COM> on 2003/07/23 18:14:11 UTC
[PROPOSAL] Expose pre-compiled JSPs without servlet mapping
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?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Posted by Remy Maucherat <re...@apache.org>.
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.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Posted by Petr Jiricka <pe...@sun.com>.
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.
Petr
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Posted by Remy Maucherat <re...@apache.org>.
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?
>
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Tim Funk wrote:
>
>> How will phantom pages be addressed? Pages where the jsp once existed
>> but then was deleted, but the corresponding class was not deleted?
>
>
> That's why I suggested an option for JspServlet that would disable this
> "optimization" and require a servlet mapping for each precompiled JSP.
>
> But your're right, in the case where the optimization is enabled,
> phantom pages will be served, so you better know what you're doing when
> turning on this optimization.
>
> However, based on your and Remy's comments, I've decided to not add this
> feature: too much headache for a small gain (reduced web.xml size).
If you'd like to add that feature to the InvokerServlet, I can change my
vote to 0. (-0 was for adding that to the JspServlet)
I recommend looking at tomcat-deployer to see what it already does
during webapp compilation, though. Indeed the gain is not very big.
(the J2EE specs will obviously have to tackle the deployment descriptor
hell issue, however)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Posted by Jan Luehe <Ja...@Sun.COM>.
Tim Funk wrote:
> How will phantom pages be addressed? Pages where the jsp once existed
> but then was deleted, but the corresponding class was not deleted?
That's why I suggested an option for JspServlet that would disable this
"optimization" and require a servlet mapping for each precompiled JSP.
But your're right, in the case where the optimization is enabled,
phantom pages will be served, so you better know what you're doing when
turning on this optimization.
However, based on your and Remy's comments, I've decided to not add this
feature: too much headache for a small gain (reduced web.xml size).
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Posted by Tim Funk <fu...@joedog.org>.
How will phantom pages be addressed? Pages where the jsp once existed but
then was deleted, but the corresponding class was not deleted?
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org