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." It shouldn't be extra complicated or require re- or duplicate-configuration of anything to whitelist one JAR. Also, it's very important that log4j-core*.jar and log4j-taglib*.jar be whitelisted by default. These are 2.0-specific JARs and they must be scanned. log4j-core contains listeners/filters/fragment to initialize and deinitialize in a Servlet container properly, and log4j-taglib contains a TLD. Nick > - The client passes the type of scan (TLD, Pluggability, etc) to the > JarScanner > - The JarScanner indicates whether or not any JAR found is an > application or container JAR > - The JacScanFilter filters the JARs returned based on scan type and on > configuration > > This addresses the above issues in the following way: > 1 - Knowing if the JAR is a container JAR or not allows the > ContextConfig class to do the right thing. > 2 - The StandardJarScanFilter can be configured per context in the same > way the StandardJarScanner can. > 3 - Same as 2. > > The StandardJarScanFilter will have enough options to implement the > requirements of 2 & 3. > > I currently have the start of this in a local git repo. Any objections to me > committing what I have to trunk and continuing there? > > > [1] http://markmail.org/message/22e3sjmsy2gt4tkw > [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=54083 > [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=54770 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
