On 14/06/2013 04:05, Nick Williams wrote:
On Jun 13, 2013, at 11:23 AM, Mark Thomas wrote:
As I make my way through the Servlet 3.1 spec reviewing all the
changes to make sure they have all been implemented, I have reached
section 8.2. There are a number of related issues here.
1. Three known issues with the current SCI / fragment handling [1]
- SCI scan does not obey class loader ordering - fragments in
container JARs are processed - Container SCIs may be exluded
2. A wish for per context jarsToSkip [2]
3. A wish for greater control over jarsToSkip [3]
These issues are all inter-related. Fixing them is going to require
either some very ugly hacks or changes to the JarScanner API.
I have started down the route of the JAR scanner API changes. The
overall idea is: - jarsToSkip is replaced by a JarScanFilter with
the default implementation doing what jarsToSkip currently does
I would request "doing what jarsToSkip currently does plus what is
wanted with jarsToScan in 3."
If it wasn't clear from my original e-mail, that is exactly what these
changes are intended to do.
It shouldn't be extra complicated or
require re- or duplicate-configuration of anything to whitelist one
JAR.
It is in no-ones interest to make anything more complicated than it
needs to be.
If a user wants to whitelist one JAR they are going to have to
reconfigure something. Tomcat can't read minds.
I agree duplicating configuration is something to be avoided where
practical.
Also, it's very important that log4j-core*.jar and log4j-taglib*.jar
be whitelisted by default.
I agree we don't want to exclude those JARs from scanning by default.
Whitelisting isn't the only way of doing that. A less broad entry in the
skip list would achieve the same result. That said, using whitelisting
for these would be a nice example to users of how it works.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
