i think all containers actually hack this part since it doesn't match the need when you are just a little bit bigger than tomcat.
today almost all apps scans (even spring ;) so would be great to get a nicer scanner. *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/14 Mark Thomas <ma...@apache.org> > 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-unsubscribe@tomcat.apache.**org<dev-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
