tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
Date Sun, 29 Jan 2012 17:36:02 GMT

--- Comment #3 from Mark Thomas <> 2012-01-29 17:36:02 UTC ---
Bringing across the list of suggestions from the duplicate...

> a. if the class is an annotation, skip it
Fixed in trunk and 7.0.x and will be included in 7.0.26 onwards.

> b. if the class doesn't extend/implement any interface skip it
Interesting. Thinking about this some more, the current isAssignableFrom() test
is actually broader than it needs to be since it will return true for
X.class.isAssignableFrom(X.class) and there is no need to add X to the
initializerClassMap in this case. Apart from that however, isAssignableFrom()
is the right test and that makes things a little more complicated to implement
solely using byte code due to how the code currently iterates over the JARs
(traversing the class hierarchy is the tricky part). Should be doable but
likely to require a fair amount of re-factoring.

> c. Look at the class hierarchy - this is actually quite easy (since
> there's only one parent) and don't load it unless it implements
> ServletContextListener
This is not correct. HandlesType specify any class or interface.

> d. if there are no Servlet initializers, don't load any classes
The code already does this.

> e. if the class needs to be loaded use a throwaway classloader
If the class must be loaded to examine it yes, but hopefully it will be
possible to avoid doing this.

In summary, b) is the only remaining problem to solve. The solution looks like
requiring caching all the javaClass instances and then doing the HandlesTypes
processing (and then throwing away the cache).

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message