Summary: | scanning HandlesTypes causes aggressive classloading | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Costin Leau <costin.leau> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.25 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All |
Description
Costin Leau
2012-01-29 11:21:47 UTC
Example bug report caused by the side effect of eager classloading in Tomcat 7: https://jira.springsource.org/browse/SPR-7440 Bug 52326 and bug 52444 touch on the same issue as well. P.S. I'm aware that metadata-complete="true" fixes the issue but it's actually a work-around not a fix. First it is false by default and not many users know about it, and second, it disables the use of annotations which means one can't use annotated ServletContainerInitializer. *** This bug has been marked as a duplicate of bug 52444 *** I'm not sure why this issue has been marked as a duplicate. This is not about long startup times or memory consumption, but rather unneeded class loading that simply breaks existing apps. Thus it's not about performance but semantics. Just for the record, you appear to have missed the point of this code. The list of ServletContainerInitializer is obtained from META-INF/services/javax.servlet.ServletContainerInitializer within each JAR, not from scanning the classes and looking for classes that implement it. The scanning is only done if there is at least one ServletContainerInitializer that defines HandlesTypes and the scanning is looking for classes that extend or implement the classes/interfaces defined by HandlesTypes. Loading the class was a quick and dirty solution (that has survived longer than I thought it might) to determining if the class meets the extends or implements test. See the duplicate for my comments on your suggestions. Short version this is doable with some refactoring and next on my todo list. Feel free to change the duplicate to a bug if you wish. I'm not that bothered since it is getting fixed anyway. You're right, I mixed the various types that trigger/are part of the scanning process but hopefully my suggestions (to try to eliminate loading by looking at the class content/dependencies inferred from the configuration) were understood. |