In an MVC web application, DelegatingWebMvcConfiguration provides the
ConversionService while also consuming WebMvcConfigurerAdapters that,
among other things, can configure HTTP message converters. Boot's
WebMvcConfigurerAdapter, WebMvcAutoConfigurationAdapter, consumes
the HttpMessageConverters bean and uses it to configure Spring MVC's
HTTP message converters. This can create a bean dependency cycle if
an HTTP message converter bean depends, directly or indirectly on
the ConversionService. An example of the cycle is:
┌─────┐
| jsonComponentConversionServiceCycle.ThingDeserializer defined in …
↑ ↓
| org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$EnableWebMvcConfiguration
↑ ↓
| org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter
↑ ↓
| org.springframework.boot.autoconfigure.web.HttpMessageConvertersAutoConfiguration
↑ ↓
| mappingJackson2HttpMessageConverter defined in class path resource [org/springframework/boot/autoconfigure/web/JacksonHttpMessageConvertersConfiguration$MappingJackson2HttpMessageConverterConfiguration.class]
↑ ↓
| jacksonObjectMapper defined in class path resource [org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration$JacksonObjectMapperConfiguration.class]
└─────┘
This commit breaks the cycle by making WebMvcAutoConfigurationAdapter
consume HttpMessageConverters lazily. This allows the adapter to be
created without triggered instantiation of every HTTP message
converter bean and all their dependencies. This allows it to be
injected into DelegatingWebMvcConfiguration without triggering an
attempt to retrieve the ConversionService.
Closes gh-9409
Clarify the cache sample and in particular that Infinispan does not
bootstrap with a default configuration file. Hence the custom
`infinispan.xml` configuration is enabled by default if Infinispan is
available on the classpath.
See gh-9417
Previously, when a web environment was converted to a
StandardEnvironment, any customizations of the source environment's
ConversionService were lost.
This commit updates the logic that performs the conversion to copy
the source's ConversionService to the converted environment, thereby
ensuring that any customizations are retained.
Closes gh-9259
See gh-9246
Prior to this commit, custom `ProtocolResolvers` set on the
`ApplicationContext` were lost when Devtools is used as the customized
`ResourceLoader` did not copy any customization made to the default
resource loader.
This commit makes sure to copy any `ProtocolResolver` set on the context.
Closes gh-9331
Different versions of Docker produce different responses when building
and tagging an image. On CI, a response with a stream like
"Successfully built 185991ffe24a" followed by a response with a
stream like "Successfully tagged spring-boot-it/centos:6.9-a23bced6"
is received. By default, for the building of an image to be considered
successful, the Docker Java client requires the stream for the last
response item to contain "Successfully built". This means that, on the
CI server, it incorrectly believes that the building of the tagged
image has failed.
This commit uses a custom BuildImageResultCallback that doesn't
require the last response to be the one that has a stream containing
"Successfully built". Instead, it looks back through the error-free
responses (newest to oldest) looking for one with a stream containing
"Successfully built".
CentOS 5 was declared EOL in March 2017 and yum on longer works
out of the box. 6.9 is the latest release of CentOS 6. Tests for
CentOS 7 have not been added as it uses systemd rather than SysVinit.
Closes gh-9395
Stephane Nicoll
Spring Buildmaster
Artem Bilan
Andy Wilkinson
Rubinson,Ethan(erubinson)
Phillip Webb
Oleg Vyukov