Mark, On 6/13/13 12:23 PM, 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 > - The client passes the type of scan (TLD, Pluggability, etc) to the > JarScanner
It might be nice if this were not a one-of-many decision, but if a client could choose more than one type. A bit-mask or a list of scan-types would be nice. I could see the same type of scanner being used for multiple different purposes. Another option would be to have a scanner that would scan for everything and then notify registered listeners. If you only care about TLDs, you just register a TLD listener. For classes, you register a class listener. A listener-based scanner would even open the doors for a webapp to be able to register its own listeners to sniff scanner events during context startup. I know this all sounds way over-engineered, but there are quite a few webapps that, when they first launch, go ahead and scan the entire reachable class loader hierarchy for classes with annotations, etc. so you get this environment where the same classes are being scanner over and over and over again just because they have to be scanned in different places for different reasons. I spoke with David Blevins about this way back in Vancouver: applications that endlessly perform JAR scanning just because the components can't seem to coordinate with each other. If there were a scanner component that could allow these unrelated components to share infrastructure, we could all save a lot of time. Such a scanning component could, much like the Digester, graduate from Tomcat and become more widely useful. -chris
signature.asc
Description: OpenPGP digital signature
