The problem this change fixes is that spring.main.sources would always
be bound to SpringApplication.sources when provided in a properties file
even if SpringApplication.run() is called directly with sources. This
led to confusion with users saying that their sources were not working
where in fact they weren't even being used.
There would be more than one way to approach this problem, but we
have chosen for now to ignore spring.main.sources completely
if the SpringApplication constructor was already called with
explicit non-empty sources. It might be preferable, if possible,
to only ignore its value in an external properties file (allowing
command line or System properties to override). If we want to change
the behaviour again, I suggest a new story should be created.
[Fixes#54185750] [bs-255]
* Added additional search in
AbstractEmbeddedServletContainerFactory.getValidDocumentRoot() to
detect a /WEB-INF/ directory in the code archive
* If the code archive is in /WEB-INF/** then we assume it is
safe to serve content from / (exposes the loader classes
but nothing sensitive from the app)
[Fixes#54345578]
* For a jar deployment add classpath:static/index.html
(works via Spring MVC mapping)
* For a war the same thing works, but so does adding
index.html to src/main/webapp (works via container
default servlet)
[Fixes#54092261] [bs-252]
Create spring-loader-tools containing utilities that can be used
with both Maven and Gradle plugings.
Refactored existing Maven plugin to use the new project.
Issue: #53129653
* Leverages existing behaviour of BeanWrapperImpl where possible
to autogrow collections and lists
* Logic for scanning and converting bean paths encapsulated in
BeanPath inner class
[Fixes#53947797] [bs-249]
@ConfigurationProperties cannot bind to Map<String,List<Thing>>
Use a ImportBeanDefinitionRegistrar to register BeanPostProcessors
rather than using @Bean definitions. Prevents warnings about
beans not having all BeanPostProcessors applied.
Phillip Webb
Dave Syer
Dave Syer