tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: JarScanning
Date Thu, 21 Feb 2013 17:52:58 GMT
On 21.02.2013 17:34, Mark Thomas wrote:
> 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.
> I think scanning of these should be made optional and disabled by
> default. This will reduce the list of JARs we have to maintain in
> jarsToSkip. I intend to implement this unless there are any objections.
> 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

OK for me.

Note though, that the following will then not be covered: whitelist some
jars with few exceptions. E.g. you want all foo-*.jar scanned except for

As always in case of conflict if there's a fixed order between include
and exclude, some situations can not be mapped to a simple configuration.

That's the reason why e.g. httpd has an "allow", "deny" and "Order
allow,deny" or "Order deny,allow".

As long as one only needs one of the tokens, e.g. only jarsToScan
(whitelist) or jarsToSkip (blacklist), an order is not needed. That's
what is already enough in most cases.

> 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
> 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.

The joy of interface evolution.

It is a relatively young interface (didn't exist before TC 7), so some
instability is needed to let it mature.

Should we make the config in the signature more generic?

> 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.

Haven't thought about the implications, but yes, per webapp would be
good, if possible via context.xml.



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

View raw message