On Feb 27, 2014, at 4:09 AM, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
> 2014-02-27 10:17 GMT+04:00 Jeremy Boynes <jboy...@apache.org>: >> >> I was thinking of supporting compile-on-start as a option where the >> initializer would scan the war for JSP(x) files and initiate the compilation >> during startup. This was intended for production use where use of JspC was >> not practical (e.g. because the actual version of runtime is not known at >> pre-compilation time) but where taking a hit on access would be undesirable. > > http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html > -> "Background JSP compilation" > > Compiling can take notable time, so I think it wouldn't be good to > delay application startup for that time. I had in mind a production configuration where the JSPs are not expected to change between deployments. IIRC, background compilation only works with JSPs that have already been hit so there is still a compilation delay on first touch. This adds jitter to the latency timings for an application. The idea was to avoid that by compiling everything during startup before the application starts taking live traffic. As you say, this would slow startup down but (assuming multiple hosts or parallel deployment) would not impact user requests. A variation would be to kick off a background task so that startup is not delayed. > >> I was thinking there to combine the TLD and JSP scans into one. > > Those are different scans. > For TLDs you have to scan jar files. > For JSPs you have to scan application resources. TldScanner#scanResourcePaths has to scan all application resources under /WEB-INF as well. For a MVC-style application where the JSPs are under /WEB-INF there can be substantial overlap. — Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
