Previously, bootRepackage's excludeDevtools property would be
overridden by the springBoot extension's excludeDevtools property.
This prevented devtools from being included by configuring it on the
repackaging task.
This commit corrects the logic so that the setting on the repackaging
task takes priority. It also adds some tests to verify the behaviour.
Closes gh-8308
The verifier's type checker is required to check that a type returned
from a method (an areturn instruction) is assignable to the method's
declared return type. When the return type is an interface, the JLS
states that it should be treated as java.lang.Object. This means that
no analysis of the type being returned is required and verification
passes. When the return type is a class, the type being returned must
be analyzed to ensure that it is compatible. This analysis causes the
return type to be loaded during verification.
Prior to this commit, BasicBatchConfigurer's
createAppropriateTransactionManager method had a return type of
AbstractPlatformTransactionManager and a branch that could return
a JpaTransactionManager. This caused the verifier to attempt to load
JpaTransactionManager so that it could check that it was assignable
to AbstractPlatformTransactionManager. This would fail when
spring-orm is not on the classpath as JpaTransactionManager could not
be loaded.
This commit updates BasicBatchConfigurer to change the return type
of createAppropriateTransactionManager so that it returns a
PlatformTransactionManager which is an interface. As described above,
this relaxes the verification of any areturn instructions in the
method and, in this particular case stops the verifier from trying to
load JpaTransactionManager.
Closes gh-8181
Instead of validating the signature against all the public keys,
we can validate it only against the public key with the kid that
matches the one in the token header.
Closes gh-8126
393cfe50 expanded the scope of spring.profiles.include so that it
could be used in any property source, and not just in a configuration
file. However, it did so in such a way that it would only take effect
when used outside of a configuration file if spring.profiles.active
was also set.
This commit updates ConfigFileApplicationListener so that included
profiles are activated when spring.profiles.active has not be set.
Closes gh-8244
This commit improves `SimpleRabbitListenerContainerFactoryConfigurer` to
use a custom `MessageConverter`. If such a bean is present, it is used
for the default factory that is auto-configured.
Closes gh-8194
In Gradle 3.3, when an API that will be removed in 4.0 is called, a
deprecation warning is output as part of the build. Users have noticed
his warning and, quite reasonably, complained about it. Unfortunately,
avoiding the warning requires the use of an API that was introduced in
Gradle 3.x which we can't use directly as we want to remain compatible
with Gradle 2.x.
This commit introduces the use of reflection to call
ProjectDependency.getTargetConfiguration() via reflection when it's
available (Gradle 3) and ProjectDependency.getProjectConfiguration()
when it's not (Gradle 2).
Closes gh-8154
The changes made in 919d0c61 meant that the value of
spring.profiles.active or spring.profiles.include was only processed
when a single property source, the property source for the config file
being read, was available. This meant that any placeholders in those
values would only be resolved against properties in the configuration
file rather than against the entire environment.
This commit updates the binding process so that placeholder resolution
is not performed during binding against a single configuration file.
Once binding has completed, the bounds values are post-processed to
resolve and placeholders that they may contain.
The two-step process described above is used in preference to binding
against the whole environment. This avoids a problem with profiles
that are active or included by property sources in the environment
being processed repeatedly.
Closes gh-8234
This commit qualifies the `CustomConversions` bean name that the Mongo
auto-configuration might create. `CustomConversions` is a common pattern
in Spring Data and other stores are using the same name.
See https://jira.spring.io/browse/DATASOLR-362
Closes gh-8225
