* ConfigurableEmbeddedServletContainerFactory now has a sessionTimeout
property
* The ServerProperties in Actuator supports it
[Fixes#53667353] [bs-243] Support setSessionTimeout
Add EmbeddedServletContainer.start() method that is used to start the
embedded servlet container once the application context has finished
being refreshed.
Refactored existing EmbeddedServletContainerFactory implementations to
no longer keep server instances locally.
Issue: #53538787
We are using a resource filter to generate that pom, so it will change
when the version changes. I prefer on balance leaving the generated
code in git in a place where it will be useful in a clean clone.
[Fixes#53189241] [bs-227]
I'll mark this as fixing the bug in tracker, but it might benefit
from some re-working at some point. The basic idea is to use
our old friend ContextRefreshedEvent to start the server listening
for connections. Delaying and making public the start() method from the
EmbeddedServletContainer doesn't help because you need the server to
start in order to get a ServletContext for Spring.
[Fixes#53538787]
Add a 'run' goal that allows maven to run a bootstrap packaged
application in-place. Similar to the maven-exec-plugin but also
adds src/main/resources to the classpath, allowing 'instant refresh'
for web developers.
Issue: #53592789
This fixed the immediate problem with Thymeleaf, but leaves open
the question of how we can prevent other race conditions developing.
As long as the container can start handling requests before the Spring
context is refreshed this will be a source of bugs.
[Fixes#53482411] [bs-235] Race condition in Thymeleaf
The spring-starter-logging is included everywhere transitively
now so logback is the default. The actuator sample explicitly
excludes the logging starter so it can have profiles for
different loggers (just as a demo).
[Fixes#53278727]
Extract command line property parsing logic from the
ConfigFileApplicationContextInitializer and instead perform it as part
of the SpringApplication initialization. This allows SpringApplications
that do not use the ConfigFileApplicationContextInitializer to still
expose command line arguments as property sources.
SpringApplicationInitializers may now implement EnvironmentAware if
they need access to the environment during early initialization.
This commit also removes the custom command line parsing logic that
was temporarily added to work around SPR-10579 which has since been
fixed upstream.
* Move Spring.main into SpringApplication.main
* User can bind command line or application.properties into
SpringApplication
* User can provide sources dynamically with --spring.main.sources
(a CSV list of class names, package names or XML resource locations)
* One side effect was to make DocumentMatchers stateless
[#52830829]
Add LoggingSystem class that can be used to configure various logging
systems in a consistent way. Mostly the code is migrated from the
LoggingApplicationContextInitializer.