[jetty-dev] [jira] (JETTY-1503) Jetty 8.1.2 scans all classes on classpath if there is >= 1xServletContainerInitializer with HandlesTypes on the classpath, regardless of metadata-complete="true"
"Barry Pitman (JIRA)" <[email protected]>
| Newsgroups | gmane.comp.java.jetty.general |
|---|---|
| Message-ID | <488331923.58995.1332932403211.JavaMail.j2ee-jira@codehaus01.managed.contegix.com> |
Barry Pitman created JETTY-1503:
-----------------------------------
Summary: Jetty 8.1.2 scans all classes on classpath if there is >= 1xServletContainerInitializer with HandlesTypes on the classpath, regardless of metadata-complete="true"
Key: JETTY-1503
URL: https://jira.codehaus.org/browse/JETTY-1503
Project: Jetty
Issue Type: Bug
Components: Servlet
Affects Versions: 8.1.2
Environment: jetty-maven-plugin 8.1.2.v20120308, spring 3.1
Reporter: Barry Pitman
I'm testing a migration to servlet 3.0 dependencies for my application, but my startup time with the jetty-maven-plugin has tripled even after setting {code}metadata-complete="true"{code} in web.xml.
I did some digging around, and found that jetty was still scanning all of the classes on the classpath because there were implementations of ServletContainerInitializer found (via the services SPI). Two instances were found, org.springframework.web.SpringServletContainerInitializer and org.apache.jasper.runtime.TldScanner.
I found this in org.eclipse.jetty.annotations.AnnotationConfiguration:
{code}
public AnnotationParser registerServletContainerInitializerAnnotationHandlers (WebAppContext context, AnnotationParser parser, List<ServletContainerInitializer> scis)
throws Exception
{
//TODO verify my interpretation of the spec. That is, that metadata-complete has nothing
//to do with finding the ServletContainerInitializers, classes designated to be of interest to them,
//or even calling them on startup.
//Get all ServletContainerInitializers, and check them for HandlesTypes annotations.
//For each class in the HandlesTypes value, if it IS an annotation, register a handler
//that will record the classes that have that annotation.
//If it is NOT an annotation, then we will interrogate the type hierarchy discovered during
//parsing later on to find the applicable classes.
...
{code}
Spring has a @HandlesTypes(WebApplicationInitializer.class) annotation, which is causing jetty to scan for all types implementing WebApplicationInitializer.
I agree that the spec isn't exactly clear on this, but Tomcat is certainly working on the assumption that metadata-complete="true" means that it shouldn't bother with ServletContainerInitializers. (see http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java -> see
{code}
protected void webConfig() {
if (webXml.getMajorVersion() >= 3) {
// Step 1. Identify all the JARs packaged with the application. If the JARs have a web-fragment.xml it will be parsed at this point.
if (!webXml.isMetadataComplete()) {
// Step 2. Order the fragments.
// Step 3. Look for ServletContainerInitializer implementations
// Step 4. Process /WEB-INF/classes for annotations
etc...
}
}
}
{code}
This is a problem for me because there is no way to tell jetty to skip the classpath scanning (45 seconds) if I have a ServletContainerInitializer on my classpath.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email