Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: dev@tomcat.apache.org
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 +0000
Message-ID: <bug-52444-78-4felpRaRx4@https.issues.apache.org/bugzilla/>
In-Reply-To: <bug-52444-78@https.issues.apache.org/bugzilla/>
References: <bug-52444-78@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=52444

--- Comment #3 from Mark Thomas <markt@apache.org> 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: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org