tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Jar scanning, SCI scanning, fragment scanning
Date Fri, 14 Jun 2013 02:31:47 GMT

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.


View raw message