Previously, when running on Java 7+, the JDBC query driven by
DataSourceHealthIndicator resulted in a call to
ResultSet.getObject(index, Object.class). When using MySQL's JDBC
driver this failed with an SQLException with the message "Conversion
not supported for type java.lang.Object". The problem does not occur
on Java 6 as the overload of getObject that takes a type does not
exist; ResultSet.getObject(index) is called instead and MySQL happily
returns whatever type it deems to be appropriate for the column.
This commit updates DataSourceHealthIndicator so that
ResultSet.getObject(index) will always be used, irrespective of the
version of Java that Boot is running on.
Closes#1306
The original fix for gh-1293 (commit 05e6af23) caused test failures due
to the fact that Spring Boot's MappingJackson2HttpMessageConverter was
added before Spring's default StringHttpMessageConverter.
This commit changes the HttpMessageConverters logic so that additional
converts are added just before any default converter of the same type.
This allows additional converters to be added whilst still retaining
the sensible ordering of the default converters.
Fixes gh-1293
It was incorrect to simply replace existing instances because you can't
tell from the instance which media types and java types it supports. This
fix just prepends the custom converters so they get higher priority.
Fixes gh-1293
Previously the server was started to make the ServletContext
available, then, to prevent requests from being handled before the
application context had been started, the connectors were stopped.
Once application context startup had completed, the connectors were
then started again. In addition to being somewhat inefficient, this
caused problems on FreeBSD where stopping the connector didn't free
up the port quickly enough for the subsequent start to then be able
to bind to it.
This commit updates the Jetty startup logic to be closer to the logic
that's used for Tomcat. Before the server is started, the configured
connectors are cached and then removed. The server is then started
without any connectors. Once application context startup has
completed, the connectors are reinstated and started.
Fixes#968
Often this change will not be important because you are binding to
a bean with strongly typed properties. A bean with a Map property,
on the other hand, won't oytherwise be able to reason about the
permitted keys so it will miss any non-enumerable property sources,
including composites whose nested sources are themselves enumerable.
Fixed gh-1294
With this change I got a simple Eclipselink version of the data-jpa
sample working. I'll push that when I get time to research it a bit more
(I needed to set up a Java agent so either that might be a problem
for our integration tests if we can't work around it).
Fixes gh-1268.
Previously any custom http code mapping would remove the default mappings. With this commit the behaviour is changed so that default mappings will stay if a custom mapping is registered. Certainly a default mapping can be overridden.
fixes#1264
This commit fixes some inconsistent or outdated keys in the
documentation. More specifically:
* allowSessionOverride is no longer a template parameter
* templateEncoding has been renamed to charSet
* Groovy templates do not have the same configuration hierarchy, hence
they don't share all settings
* spring.data.elasticsearch.local does not seem to exist
* flyway prefix and suffix should be sqlMigrationPrefix and suffix
* spring.rabbitmq.virtualHost had a typo
* endpoints.error.path is not a valid property
* shell.command-path-patterns had a typo
* spring.datasource.max-wait had a typo
Fixes gh-1226
Before this change a property whose key was in a non-enumerable property source would
not resolve placeholders, leading to ${style} values in @ConfigurationProperties beans
even if the placeholders ere resolvable.
Both embedded containers need to be checked after starting to ensure that they
are actually running. With Jetty it's just a question of catching an exception
but with Tomcat it's harder (the current solution involves duplicating some
code from initialize() into start() essentially checking the lifecycle state).
Also adjusted the log levels to prevent noise at WARN level by default when
this happens (since the exception is logged and rethrown anyway).
There is still the issue of whether to fail the build in Maven or Gradle
(separate issue really).
Fixes gh-1232
The problem with the old code is that it worces a ResourceBundle to
initialize with the default encoding (and that is then cached in the
JDK) during @Condition evaluation (so before the encoding is known).
Includes test for swedish messages
Fixes gh-1228
Due to a mistake in Spring Batch 3.0.0 it has been necessary to
introduce a breaking API change (the addition of
BatchConfigurer.getJobExplorer()) in the 3.0.1 release. This commit
updates Boot to use 3.0.1 and modifies the Batch auto-configuration
and associated tests to implement the new method.
Update TomcatEmbeddedServletContainer so that Connectors are removed
during initialization and re-added when the start() method is called.
This prevent protocol handlers from being bound then immediately
unbound. It also ensure that any additional connectors that may have
been added don't accidentally start to accept traffic (which could cause
potential deadlock issues).
Fixes gh-1212
User can now add credentials, vhost and protocol prefix (amqp://)
to any or all of the addresses, extending the format beyond that accepted
bu the rabbitmq client, but making it cloud friendly. Only one of
the addresses needs those properties and all are optional. Port
also defaults to 5672 in an address.
This commit refines the changes made under 4be688aa. 4be688aa made the
default jar task a special case which broke repackaging of the archive
produced by the default war task.
This commit refines RepackageTask’s logic so that, when it’s enabled,
it will repackage a jar task’s archive if:
- The jar task is equal to RepackageTask.withJarTask
- The name of the jar task is equal to RepackageTask.withJarTask
- RepackageTask.withJarTask is null, the jar task is not referenced
by another RepackageTask’s withJarTask, and the jar task has an
empty classifier
The last of these three is the default case and ensures the, when the
Spring Boot plugin is applied, default jar and war artifacts are
repackaged. The classifier check is required to prevent default source
and javadoc artifacts from being repackaged.
Fixes#1204
Andy Wilkinson
Phillip Webb
Dave Syer
Andy Wilkinson
Christian Dupuis
ddebree
Stephane Nicoll
Ilayaperumal Gopinathan
Lukasz Kryger
Spring Buildmaster
Gary Russell