- 29 Jan, 2018 40 commits
-
-
Phillip Webb authored
Migrate existing code to the new `LambaSafe` callback handler. Closes gh-11584
-
Phillip Webb authored
Add `LambdaSafe` utility that provides a consistent way to deal with the problems that can occur when calling lambda based callbacks. See gh-11584
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-11837
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-11836
-
Andy Wilkinson authored
Closes gh-11501
-
Andy Wilkinson authored
-
Andy Wilkinson authored
* gh-11790: Polish "Configure ErrorReportValve not to report stack traces" Configure ErrorReportValve not to report stack traces
-
Andy Wilkinson authored
Closes gh-11790
-
Phillip Webb authored
-
Alex Panchenko authored
See gh-11790
-
Andy Wilkinson authored
* gh-11834: Upgrade to Spring AMQP 2.0.2
-
Gary Russell authored
Closes gh-11834
-
Andy Wilkinson authored
-
Andy Wilkinson authored
* gh-11835: Upgrade to Spring AMQP 1.7.6
-
Gary Russell authored
Closes gh-11835
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-11660
-
Stephane Nicoll authored
Closes gh-11793
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-11717
-
Andy Wilkinson authored
Closes gh-11833
-
Andy Wilkinson authored
Closes gh-11832
-
Andy Wilkinson authored
Closes gh-11831
-
Andy Wilkinson authored
Closes gh-11830
-
Andy Wilkinson authored
-
Andy Wilkinson authored
Closes gh-11829
-
Andy Wilkinson authored
Closes gh-11828
-
Andy Wilkinson authored
By default, JUL configures a single root handler. That handler is a ConsoleHandler. Previously, we removed all root handlers from JUL but this is problematic in environments where other handlers are registered with JUL and those handlers need to be retained. 0679d436 attempted to fix the problem by leaving the root handlers in place and only adding and removing the bridge handler. This resulted in log output from Tomcat (and anything else that uses JUL) being duplicated. This commit makes another attempt at tackling the problem. It attempts to detect JUL's default configuration (a single root handler that's a ConsoleHandler) and only removes the handler if it appears to be from the default configuration. For environments where default JUL configuration is being used, this will prevent duplicate logging and for environments where custom JUL configuration is being used, this will prevent that configuration from being undone. Closes gh-8933
-
Stephane Nicoll authored
Closes gh-11822
-
Andy Wilkinson authored
Previously, the test in MetricsAutoConfigurationIntegrationTests was testing the functionality of WebMvcMetricsFilter to verify that the auto-configuration had registered the filter for async dispatches. This test was complex and covered the same code as a test in WebMvcMetricsFilterTests. This commit reworks the test to examine the dispatcher types on the filter registration directly instead. Closes gh-11826
-
Andy Wilkinson authored
Closes gh-11711
-
Stephane Nicoll authored
Closes gh-11794
-
Stephane Nicoll authored
See gh-11794
-
Stephane Nicoll authored
* pr/11815: Use Spring Session BOM in dependency management
-
Vedran Pavic authored
Closes gh-11815
-