Mark, On 6/14/13 3:16 AM, Mark Thomas wrote: > 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.
Well, crap. I had never seen those before. I'm curious, though. Thinking about this the other day with a colleague who was complaining about some kind of Spring configuration that evidently loaded every class available on the classpath and kept them in memory (thus leading to heap and PermGen issues), I concluded that the only sane way to do this kind of probing would be to probe everything in a ClassLoader that was intended to be discarded after the probing as to avoid loading classes unnecessarily. If an SCI retains a reference to any of the Class objects in the Set<Class> parameter, that hypothetical throw-away ClassLoader is no longer thrown-away. > 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. Thanks for pointing that out. I actually had no idea. > 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. I think you are absolutely right. My idea was born before I knew that SCIs existed. Time to re-read the API now that I'm actually starting to update all my webapps towards 3.0. Thanks, -chris
signature.asc
Description: OpenPGP digital signature
