Since @ConfigurationProperties binding uses a single instance of
PropertySourcesPropertyValues per bean, there doesn't seem to be
any issue with using a normal LinkedHashMap. Then the order
passed in as PropertySources will be preserved.
Fixes gh-2487
Previously, if a BeanPostProcessor bean was declared in a configuration
class that depended on the persistence context, packages to scan would
not be configured on the LocalContainerEntityManagerFactoryBean. This
was due to the BeanPostProcessor bean triggering the early instantiation
of the LCEMFB before EntityScanBeanPostProcessor, the BeanPostProcessor,
that applies the @EntityScan configuration, had been given a chance to
configure it.
This commit updates EntityScanBeanPostProcessor to implement Ordered
with an order of zero. This ensures that its ordering is predictable
and that it will be driven before any unordered BeanPostProcessor. This
means that, unless the user has specifically ordered their
BeanPostProcessor to run before EntityScanBeanPostProcessor,
LCEMFB’s packages to scan will be configured as expected.
Fixes gh-2478
If an application defines a custom RepositoryRestMvcConfiguration, all
Spring Boot defaults are lots. While this sounds sensible, it can be
confusing as Spring Boot exposes properties (`spring.data.rest.*`) that
are no longer honored.
RepositoryRestMvcBootConfiguration is now public and can be used as an
extension point for those who need to customize the Spring Data REST
configuration and keep boot's specific defaults.
Fixes gh-2392
Update ConditionEvaluationReport so that, whenever a negative outcome
is added for a source, any existing outcomes for inner classes of that
source are updated with a non-matching outcome that indicates that the
outer configuration did not match.
Conditions are evaluated in two phases; PARSE_CONFIGURATION first and
REGISTER_BEAN second. If a parent class’s conditions match in
PARSE_CONFIGURATION then its inner classes will have their
PARSE_CONFIGURATION conditions evaluated. If they all match, the inner
class will be reported as a positive match in the auto-configuration
report even if the outer class does not match as a result of the
subsequent evaluation of a REGISTER_BEAN condition.
Fixes gh-2122
Tomcat 8's default DataSource implemention is an MBean. Previously,
when such a DataSource was consumed from JNDI and an MBeanExporter had
been auto-configured an attempt would be made to export this MBean to
the MBean server. This would fail due to Tomcat having already
registered the MBean.
This commit updates JndiDataSourceAutoConfiguration to instruct the
MBeanExporter (if there is one) not to export a DataSource MBean
that's been retrieved from JNDI. The assumption is that any MBean in
JNDI will have already been registered with the MBean server by the
same infrastructure that registered it with JNDI.
Fixes gh-2397
preferred-mapper has been renamed to preferred-json-mapper to make it
clear that it only affects the JSON mapper and that the XML mapper
that will be used (if any) is unaffected
See gh-2247
This commit rewords the changes made in d718a80 so that simply adding
Gson to the classpath isn't sufficient to stop Jackson being used
for HTTP JSON mapping. To use Gson, the user must now either remove
Jackson from the classpath (not an option if they also wish to use
the Actuator) or configure the spring.http.converters.preferred-mapper
property with a value gson.
Closes gh-2247
Previously the recommendation when a user wanted to use Gson was to
exclude Jackson from the classpath and add Gson. This worked fine until
the user also want to use the Actuator which requires Jackson. To get
over this hurdle the user could leave Jackson on the classpath and
perform their own HttpMessageConverter configuration and register a
GsonHttpMessageConverter instead of or before any Jackson-based
converter. A little complicated, but it worked.
This commit makes things easier by updating the auto-configuration for
HTTP message converters to prefer Gson when both Gson and Jackson are
on the classpath, i.e. in the presence of both, a
GsonHttpMessageConverter will be auto-configured and a
MappingJackson2HttpMessageConverter won’t be. This allows an
application to easily use Gson while allowing the Actuator to continue
to use Jackson.
Closes gh-2247
By default, SnakeYAML will convert a timestamp-like string into a
java.util.Date. This differs to properties file-based configuration
where the values are always strings. Dates are problematic as the
round trip (string -> Date -> string) can change the value. For example,
“2015-01-27” becomes “Tue Jan 27 00:00:00 GMT 2015”.
This commit updates YamlPropertySourceLoader to use a Yaml with a
custom Resolver subclass that suppresses the addition of the implicit
resolver for timestamps. Supressing the addition of the unwanted
resolver, rather than overriding addImplicitResolvers and registering
the resolvers that we do want, ensures that we get all of the other
default Resolvers in their default order.
Fixes gh-2422
The Maven plugin allows spring-boot:run to be configured so that
resources are loaded from their output location rather than from
src/main/resources. This commit adds an equivalent configuration
option to the Gradle plugin. To disable source resources from being
added to the classpath in place of those in the output location
the configure the bootRun tasks like this:
bootRun {
addResources = false
}
Closes gh-2431
Spring Integration's FileWritingMessageHandler uses a .writing file
while it's in the process of writing a message to disk and then
performs a rename (depending on the OS and filesystem this may or may
not be atommic) to create the .msg file. Prior to this commit the
test was finding the temporary .writing files and examining them. This
could lead to a FileNotFoundException being thrown as the temporary
file was deleted while the test was trying to read its contents.
This commit updates the test to only look for files with a .msg suffix
Fixes gh-2428
The main change in this commit is to introduce a new BuildHandler
abstraction. A BuildHandler is responsible for producing the metadata
for a build. Two implementations are provided; one for standard builds
and one for incremental builds. This change means that the annotation
processor is no longer concerned with the two different build types
and can use the same logic in each case.
The code for reading and writing metadata files has also been moved
out into a separate class, MetadataStore, to allow it to be easily
utilised from multiple places.
Closes gh-2313
This commit udpdates the metadata annotation processor so that change
data from an incremental build is merged with the metadata from the
previous build.
Closes gh-2321
While `logging.level` is managed in a dedicated way in
`LoggingApplicationListener`, the value of the map are String values
representing the level to apply. The meta-data now exposes that type
instead of raw `java.lang.Object`
Closes gh-2388
Dave Syer
Andy Wilkinson
Stephane Nicoll
Phillip Webb
izeye
Kris De Volder