- 08 Jun, 2017 3 commits
-
-
Stephane Nicoll authored
Closes gh-9383
-
Stephane Nicoll authored
-
Stephane Nicoll authored
Closes gh-9385
-
- 07 Jun, 2017 19 commits
-
-
Stephane Nicoll authored
-
Stephane Nicoll authored
Closes gh-9280
-
Stephane Nicoll authored
-
Stephane Nicoll authored
* pr/9429: Upgrade to Spring AMQP 1.6.10
-
Artem Bilan authored
Closes gh-9429
-
Andy Wilkinson authored
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
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Stephane Nicoll authored
-
Stephane Nicoll authored
Closes gh-9084
-
Stephane Nicoll authored
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
-
Andy Wilkinson authored
Closes gh-9423
-
Andy Wilkinson authored
Closes gh-9422
-
Andy Wilkinson authored
See gh-9425
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-9424
-
Andy Wilkinson authored
* gh-9259: Polish "Copy conversion service when performing environment conversion" Copy conversion service when performing environment conversion
-
Andy Wilkinson authored
Closes gh-9246
-
Rubinson,Ethan(erubinson) authored
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
-
- 06 Jun, 2017 7 commits
-
-
Andy Wilkinson authored
See gh-9248
-
Andy Wilkinson authored
Closes gh-9248
-
Stephane Nicoll authored
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
-
Andy Wilkinson authored
Closes gh-9054
-
Andy Wilkinson authored
Closes gh-9360
-
Andy Wilkinson authored
Closes gh-9410
-
Andy Wilkinson authored
Closes gh-8927
-
- 05 Jun, 2017 1 commit
-
-
Andy Wilkinson authored
Closes gh-9407 Closes gh-9135
-
- 03 Jun, 2017 7 commits
-
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
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".
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
- 02 Jun, 2017 3 commits
-
-
Phillip Webb authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
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
-