The JMS MessageListenerContainer supports the PlatformTransactionManager
abstraction with either a `JmsTransactionManager` for local transactions
or `JtaTransactionManager` for distributed transactions. The former is
kind of deprecated (`setTransacted` should be used instead). In any case,
any other `PlatformTransactionManager` implementation is not supported.
Update JmsAnnotationDrivenConfiguration to only associated a JTA
transaction manager, if any.
Closes gh-3150
Only affects the default AuthenticationManagerBuilder (so when users
are not overriding the default global user details). Makes the
UserDetailsService effectively available as it would be if we used
AuthenticationManagerBuilder.inMemoryAuthentication() as a
shared object in the HttpSecurity.
Fixes gh-3152
Update `ConfigurationPropertiesReportEndpoint` so that properties that
are set with a Boolean class but read with a boolean primitive still
appear in the report. The allows the Endpoint.isEnabled() property to
be displayed.
Fixes gh-2929
Do not rely on the packaging type to figure out what the extension of the
main artifact will be. So far, using `jar` and `war` packaging for `.jar`
and `.war` files worked by chance.
We know retrieve the actual extension as provided by Maven's
`ArtifactHandler`.
Fixes gh-2762
Previously, CommonsLoggingLiquibaseLogger referred to its
configured level and the underlying Commons Logging log when
determining if logging was enabled for a particular level. This did
not work as intended as setLogLevel was never called leaving the
configured level stuck at its default value of INFO. As a result of
this any logging at levels below INFO would not be output,
irrespective of the configuration of the underlying logging framework.
This commit updates CommonsLoggingLiquibaseLogger to rely purely on
the Commons Logging log when determining whether or not logging for
a particular level is enabled. This brings the implementation into
line with liquibase-slf4j [1] which provides similar functionality,
albeit using SLF4J rather than Commons Logging
Closes gh-2916
[1] https://github.com/mattbertolini/liquibase-slf4j/blob/master/src/main/java/liquibase/ext/logging/slf4j/Slf4jLogger.java
Previously, when SpringApplicationContextLoader created a
SpringApplication and used it to load the test’s application context,
it relied upon SpringApplication correctly deducing the application’s
main class. This would result in the wrong class being deduced as the
application’s main method is not called so the test runner’s main method
would be found instead.
This commit updates SpringApplicationContextLoader to explicitly set
SpringApplication’s main class to be the current test’s class. While
not strictly the application’s main class, it is the next best thing
available in this situation and prevents misleading log messages and
application versions from being logged.
Fixes gh-2930
When a Java 8 JVM is launched with -XX:MaxPermSize a warning message
is output indicating that the option will be ignored. This causes the
CLI tests that assert that no error output has been produced to fail.
This commit updates the CLI's integration test harness to remove
JAVA_OPTS from the environment of the CLI process. This prevents any
unwanted max perm size configuration from leaking into that
environment and breaking the build.
While this is a breaking change, continuing with Spring Social
Facebook 1.1.x is also broken as it is no longer compatible with
Facebook's API. Upgrading to 2.0.1.RELEASE may require some changes
to be made to users' applications, but it will allow their
applications to use the Facebook API once again.
Closes gh-2837
Previously ManagementSecurityAutoConfiguration used Spring Security's
default realm of "Realm" when authentication failed. This was confusing
because when prompted for authentication (i.e. no credentials provided)
the realm "Spring" was requested.
This commit ensures the Realm that is used is consistent for all of of the
security auto configuration.
Fixes#2466
