Find why DispatcherServlet is initialized on first request on JVM and startup on native image

[sdeleuze]

This difference of behavior is a real issue since DispatcherServlet early initialization triggers DispatcherServlet.properties + reflection initialization which requires more configuration on GraalVM native.

This seems to be triggered by a difference of behavior in Tomcat connection pool on native image, not sure why yet.

With this + spring-projects/spring-framework#25209 and related Spring Fu update, we should be able to remove DispatcherServlet substitution.

[fhanik]

Hi @sdeleuze

Servlet Initialization

I took a brief look on what boot is doing. Right now, Spring Boot is configuring servlets for lazy initialization.

When I say initialization, I specifically refer to

javax.servlet.Servlet.init(ServletConfig config);

modifying application.properties to include the line

spring.mvc.servlet.load-on-startup=1

will ensure that the DispatcherServlet is loaded and initialized at startup instead of on the first request (first request = default)

When I ran this example, I'm seeing the correct behavior for native-image as well as JVM for both 1 and -1 values

DispatcherServlet.properties

For both JVM and native-image, the DispatcherServlet.properties file is loaded when the class is loaded, during application startup. (not on first request)

On the JVM, DispatcherServlet.properties is loaded SpringApplication.run calls refreshContext
On native-image, DispatcherServlet.properties is loaded SpringApplication.run calls refreshContext

I'm seeing the same behavior for both runtime environments.

[sdeleuze]

@fhanik I agree with the behavior you describe, but what I was not able to find is how to have the same behavior on JVM and native image with Boot defaults (lazy servlet loading).

On native image, it seems we have an eager loading of the servlet by default (to be confirmed). Is it what you observe as well?

[sdeleuze]

After more tests it indeed seems consistent so I close this issue.