Re: TldScanner + Config, was: Jasper Improvements
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 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. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: TldScanner + Config, was: Jasper Improvements
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
TldScanner + Config, was: Jasper Improvements
On Feb 26, 2014, at 4:55 PM, Greg Wilkins gr...@intalio.com wrote: Just in case it was missed, here is the pull request I generated: https://github.com/apache/tomcat/pull/4 Happy to talk about individual changes either in the comments there or here. Related to the TldScanner changes, I’m assuming you have some integration code in Jetty that is sub-classing the initializer and overriding newTldScanner? 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. I was thinking there to combine the TLD and JSP scans into one. There may be other reasons to scan e.g. looking for tag-plugins packaged in jars (no XML config needed a bit like a Tld). We also have an issue where Jasper is very reliant on system properties and the Options built from the init-params of JspServlet. In short, I’m wondering if instead of the subclassing we define a JasperConfiguration interface and have the initializer look for an instance of it in a context attribute. The configuration there would allow the container to replace parts of Jasper’s initialization (e.g. by supplying a CollectionURL of pre-scanned TLDs, by identifying TLDs provided by the container” etc.) and other configuration on a per-context basis. Would something like that work for you? Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
