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 15:57:19 GMT

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.


View raw message