tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: JarScanning
Date Fri, 22 Feb 2013 14:11:03 GMT
2013/2/21 Mark Thomas <>:
> An issue at work prompted me to take another look at this thread:
> There are some useful things there that I think it is worth following up on.
> jarsToScan
> This is a little more complicated.
> First of all, how does it work? The suggestion is:
> - If jarsToScan matches, scan it
> - else if jarsToSkip matches, skip it
> - else scan it

In other words, it is a "force scan" option.

> Assuming that the above is acceptable, it would require the following:
> a) three new system properties
>      tomcat.util.scan.DefaultJarScanner.jarsToScan
>      org.apache.catalina.startup.ContextConfig.jarsToScan
>      org.apache.catalina.startup.TldConfig.jarsToScan

I am not so interested in global options, but am very interested in
per-webapp ones.

My current thought is that a nice solution could be to have the
same-named parameters in a ServletContext.
So that those can be defined in WEB-INF/web.xml or using Parameter
element in context.xml.

>From implementation point of view though
a) it will need some code to evaluate the effective value before usual
merging of all web fragments has happened
b) just document that the value cannot be specified in a web fragment
or annotation, because of chicken vs. egg pattern.

We may add a separate page to the configuration reference guide to
document supported initialization parameters. E.g. websockets
implementation in trunk already defines two of those,
in org.apache.tomcat.websocket.server.Constants

> b)  add a parameter to JarScanner.scan()
> There are a couple of issues here.
> 1. Backwards compatibility. Adding the parameter to JarScanner.scan()
> will break any custom Jar scanners. Without that parameter it would not
> be possible to have different jarsToScan for pluggability and TLDs.

We do add methods to interfaces (e.g. Context), but we never remove them.

I think the guidance here is that it allows a 3rd party class to be
compiled for a later version of Tomcat and used with earlier ones as

So I propose to add a second "scan" method and deprecate the first one.

> 2. (and an issue with the current code [1]). These settings are all
> global rather than per web application. I would prefer that they were
> per web application with defaults configured globally. It is complicated
> by the fact that the JARs to skip/scan may vary depending on how the
> JarScanner is used.
> [1]

Best regards,
Konstantin Kolinko

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

View raw message