tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jasper-howto.xml
Date Mon, 04 Oct 2004 22:08:02 GMT
Jan Luehe wrote:

> Remy Maucherat wrote:
>> Jan Luehe wrote:
>>> Hi Remy,
>>> wrote:
>>>> remm        2004/10/04 10:39:46
>>>>   Modified:    jasper2/src/share/org/apache/jasper/resources
>>>>                jasper2/src/share/org/apache/jasper
>>>>                jasper2/src/share/org/apache/jasper/compiler 
>>>>                webapps/docs changelog.xml jasper-howto.xml
>>>>   Log:
>>>>   - Allow configuring the interval following a compilation during 
>>>> which a JSP will not be checked for modifications.
>>> how is this different from the 'checkInterval' option?
>> The check interval is in seconds, and is for the background reloading 
>> thread. This means "at most one check every X ms".
>> I did consider reusing it, but since the unit was different, I chose 
>> not to.
> I think this new option is going to confuse users.
> If we wanted to reduce the number of last-modified checks in
> development mode, we should at least try to leverage the existing
> option and use the same unit. The default for the new option
> (4000ms) seems to imply that "seconds" may be a reasonable unit
> for it as well.
> Also, I think it is more intuitive if we check for last modification
> date on each access in dev mode. I don't think perf improvements are
> important in dev mode.

I feel strongly about this. Dev mode is the default, and is needed for 
some special purpose stuff (where JSPs are regenerated on the fly), so 
it need to perform relatively well.

IMO, the background reloading thread is way too complex and buggy. It 
should go in favor of a much simpler mechanism (if you really want only 
one thing; personally, I would keep both, as it's more flexible).

>   +<li><strong>modificationTestInterval</strong> - If development has

> to be set to
>   +<code>true</code> for any reason (such as dynamic generation of 
> JSPs), setting
>   +this to a high value will improve performance a lot.</li>
> Why won't dynamic generation of JSPs work in nondev mode? Notice that
> in JspServleWrapper, we compile if
>   options.getDevelopment() || firstTime

It works for the first compilation, of course. But most people who use 
that obvious refresh their JSPs.

Overall, I think that having two attributes is appropriate.


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

View raw message