On 14/06/2013 16:57, Christopher Schultz wrote:
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.
The early Tomcat 7 implementations did it like this - loaded every class
and then examined the class object. More recent implementations use BCEL
to look at the byte code. It is faster and uses less memory. We also use
caching to ensure each class is only processed once.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
