- 06 Jun, 2017 1 commit
-
-
Vedran Pavic authored
If the auto-configured `Scheduler` instance backed by JDBC job store is used as a dependency in an application component, the initialization of `Scheduler` will be triggered before `QuartzDatabaseInitializer`. This will result in failure due to schema not being prepared in time for `Scheduler` to populate job details. This commit ensures `QuartzDatabaseInitializer` is initialized before the auto-configured `Scheduler` by introducing a dependency between the two. See gh-9411
-
- 05 Jun, 2017 6 commits
-
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-9407 Closes gh-9135
-
Stephane Nicoll authored
* pr/9404: Polish "Document InfluxDB support" Document InfluxDB support
-
Stephane Nicoll authored
Closes gh-9404
-
Huang YunKun authored
See gh-9404
-
Stephane Nicoll authored
This commit removes the `client` namespace for InfluxDB as the component that is created is `InfluxDB`, not `InfluxDBClient` or something. This aligns with all the other url/user/password properties Spring Boot provides already See gh-9066
-
- 03 Jun, 2017 11 commits
-
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
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
-
Andy Wilkinson authored
-
- 02 Jun, 2017 22 commits
-
-
Phillip Webb authored
-
Phillip Webb authored
-
Phillip Webb authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
See gh-6299
-
Andy Wilkinson 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
-
Stephane Nicoll authored
-
Stephane Nicoll authored
-
Stephane Nicoll authored
-
Stephane Nicoll authored
* pr/8595: Fix OptionalLiveReloadServer create bean
-
Oleg Vyukov authored
Closes gh-8595
-
Andy Wilkinson authored
Closes gh-9391
-
Stephane Nicoll authored
This commit is a companion of what was done in #6013. As HikariCP is now the default connection pool, the jdbc and jpa starters no longer provide `tomcat-jdbc`, but rather `HikariCP`. Closes gh-9392
-
Andy Wilkinson authored
See gh-9066 See gh-4299
-
Andy Wilkinson authored
Closes gh-9386
-
Andy Wilkinson authored
Closes gh-6299
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-9073
-
Andy Wilkinson authored
Glassfish bundles an old and incomplete version of Glassfish. By default, this leads to some of Jackson's classes being loaded from inside the war file and others being loaded from Glassfish itself. This mixture of versions does not end well and the application fails to deploy. This commit adds a Glassfish-specific deployment descriptor to invert the web app class loader's delegation model. Rather than preferring classes available from its parent, it will now prefer those packaged inside the war file. Closes gh-9391
-