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.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to