tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject TldScanner + Config, was: Jasper Improvements
Date Thu, 27 Feb 2014 06:17:40 GMT
On Feb 26, 2014, at 4:55 PM, Greg Wilkins <gregw@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


Mime
View raw message