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