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 Collection<URL> 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
