Startup time in 3.1.0.RELEASE

Hi,

since upgrading from Spring 3.0.6.RELEASE to 3.1.0.RELEASE the startup time of our application has multiplied by 3 or 4 (local, with Tomcat 7). Is anybody else experiencing this?

I suspect the new SpringServletContainerInitializer, because after it hangs for a long time, the output says: INFO: No Spring WebApplicationInitializer types detected on classpath.

Is there a way to disable the scanning?

Best, Thomas.

If you don't use this feature specify metadata-complete="true" in your web.xml header.

Code:

---

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    metadata-complete="true">

---

This tells the container not to scan for classes implementing ServletContainerInitializer and that all web configuration is in the web.xml.

Alright, thanks! That brings it down to below the 3.0.6 startup time.
I couldn't find any documentation about what this attribute does exactly in Spring, are there any other side-effects when setting metadata-complete="true"? Other annotations like @RequestMapping, @Autowired etc. still seem to work...

That has nothing to do with spring :). It is something specified in the servlet 3.0 spec. As I stated it tells the container (in this case Tomcat 7) to not scan for classes implementing ServletContainerInitializer (which is something new in the servlet 3.0 spec it allows you to write a web app without providing a web.xml and use a class implementing that interface to register your servlets etc. Spring provides a wrapper with the SpringServletContainerInitializer which in turn scans for the WebApplicationInitializer interface. So basically your full class path is now scanned twice which in case of a large class path can be killing for your startup time).

Ah, got it now.. sorry, confused xml-free container-configuration (which was new to me!) and xml-free Spring configuration. Superb, thanks again for your explanation.

Odd, I got rid of the problem earlier on with metadata-complete="true" with Spring 3.0.6 but it comes back now with the upgrade to 3.1.0.

The web.xml header is for servlet 2.5 though:

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
metadata-complete="true"
version="2.5">

This works fine with 3.0.6, it skips the classpath scanning, but it doesn't with 3.1.0.
Needs a minute or so to display "No Spring WebApplicationInitializer types detected on classpath" where it's not even logged with 3.0.6....

Odd, I got rid of the problem earlier on with metadata-complete="true" with Spring 3.0.6 but it comes back now with the upgrade to 3.1.0.

The web.xml header is for servlet 2.5 though:

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
metadata-complete="true"
version="2.5">

This works fine with 3.0.6, it skips the classpath scanning, but it doesn't with 3.1.0.
Needs a minute or so to display "No Spring WebApplicationInitializer types detected on classpath" where it's not even logged with 3.0.6....

Well spring 3.0.6 has no WebApplicationInitializer as it is a feature added to 3.1.0. Also for the metadata-complete="true" to work you have to have a servlet 3.0 web app, which yours isn't. Also it does absolutely nothing for web 2.5 nor for a spring 3.0 application next to that that option has NOTHING to do with spring.

Hi,

I would also like to remark that if you do not include

Code:

---

metadata-complete="true"

---

in your servlet 3.0 web.xml while using Spring 3.1, you will see how your startup memory usage duplicates (even triplicates in some cases) in comparission with Spring 3.06

I guess this is because tomcat will load into the permgen all classes being scanned. Ugly thing indeed.

Quote:

---

Originally Posted by monzonj

I guess this is because tomcat will load into the permgen all classes being scanned. Ugly thing indeed.

---

Your guess is right (thanks for pointing me the cause of the problem) - while performing scanning, tomcat is saving detailed class information into its internal cache. In later processing it only needs names of superclass and implemented classes for each class in cache.

I've reported that as bug (technically, this is not a bug, but a very lousy programming) and now I am waiting for response.