[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"

    [ https://jira.codehaus.org/browse/JETTY-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=295975#comment-295975 ] 

Jan Bartel commented on JETTY-1503:
-----------------------------------

Michal,

jsp-api and impl jars should be on the container path, not in WEB-INF/lib. If you have them in your war, then you should delete them.

cheers
Jan
                
> 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
>            Assignee: Jan Bartel
>
> 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