tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Jar scanning, SCI scanning, fragment scanning
Date Fri, 14 Jun 2013 07:16:10 GMT
On 14/06/2013 03:31, Christopher Schultz wrote:

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

That is what ServletContainerIniiializers are for.

They only handle class files but the other types (e.g. TLDs) are always 
in known locations and are inexpensive to find. The expensive bit is 
scanning all the classes and SCIs provide a mechanism to do that only 
once for all interested parties.

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

That is exactly what SCIs do.

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

Then the libraries doing the scanning need to be updated to use the 
container provided scanning mechanism that is already in place.

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

I really don't see the need for this at all given that SCIs are 
available. If there are use cases that SCIs don't meet then extending 
SCIs is the way to go so the same feature is available in any container.


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

View raw message