tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Jar scanning, SCI scanning, fragment scanning
Date Thu, 13 Jun 2013 16:23:58 GMT
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
- 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

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?


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

View raw message