Corrected the documentation to refer to file as tests.groovy, rather
than test.groovy. Updated cope snippet as tests.groovy should expect
"Hello World!" rather than "Hello World".
Closes gh-1593
Enhance JacksonAutoConfiguration to configure features on the
ObjectMapper it creates based on the following configuration
properties:
spring.jackson.deserialization.* = true|false
spring.jackson.generator.* = true|false
spring.jackson.mapper.* = true|false
spring.jackson.parser.* = true|false
spring.jackson.serialization.* = true|false
The final part of each property name maps onto an enum. The enums are:
deserialization: com.fasterxml.jackson.databind.DeserializationFeature
generator: com.fasterxml.jackson.core.JsonGenerator.Feature
mapper: com.fasterxml.jackson.databind.MapperFeature
parser: com.fasterxml.jackson.core.JsonParser.Feature
serialization: com.fasterxml.jackson.databind.SerializationFeature
Closes gh-1227
Spring Data Redis 1.4.0 introduced Redis Sentinel support. When
specified, RedisConnectionFactory uses the Sentinel configuration to
determine the current master.
Sentinel configuration can be specified using two new properties:
spring.redis.sentinel.master and spring.redis.sentinel.nodes.
For example:
spring.redis.sentinel.master=mymaster # name of redis server
spring.redis.sentinel.nodes=127.0.0.1:26379,127.0.0.1:26380
Alternatively, a bean of type RedisSentinelConfiguration can be declared
and it will be used to configure the connection factory.
Note: At this time, Sentinel support is only available for Jedis
Closes gh-1337
This commit deprecates the proprietary EnableRabbitMessaging annotation
in favour of the standard @EnableRabbit introduced as of Spring Rabbit
1.4.
Fixes gh-1494
This commit improves DataSourceMetadata to expose the validation
query. This can be used by DataSourceHealthIndicator as the query
to use instead of "guessing" which query could be applied according
to the database type.
Fixes gh-1282
This commit adds an abstraction that provides a standard manner to
retrieve various metadata that are shared by most data sources.
DataSourceMetadata is implemented by the three data source
implementations that boot supports out-of-the-box: Tomcat, Hikari and
Commons dbcp.
This abstraction is used to provide two additional metrics per data
source defined in the application: the number of allocated
connection(s) (.active) and the current usage of the connection pool
(.usage).
All such metrics share the 'datasource.' prefix. The prefix is further
qualified for each data source:
* If the data source is the primary data source (that is either the
only available data source or the one flagged @Primary amongst the
existing ones), the prefix is "datasource.primary"
* If the data source bean name ends with "dataSource", the prefix is
the name of the bean without it (i.e. batchDataSource becomes batch)
* In all other cases, the name of the bean is used
It is possible to override part or all of those defaults by
registering a bean with a customized version of
DataSourcePublicMetrics.
Additional DataSourceMetadata implementations for other data source
types can be added very easily, check
DataourceMetadataProvidersConfiguration for more details.
Fixes gh-1013
This commit binds RepositoryRestConfiguration to the spring.data.rest
prefix so that any of its property can be customized through the
environment.
If a RepositoryRestMvcConfiguration is defined in the context, those
customization do not apply, as it was the case before.
Fixes gh-1171
Add `spring.datasource.jndi-name` property to allow a DataSource to be
looked up from JNDI as an alternative to defining a URL connection.
Fixes gh-989
Rework flexible PublicMetrics registration introduced in 2be6b3e4 to
restore compatibility with v1.1 VanillaPublicMetrics. The new
MetricReaderPublicMetrics class now exposes metrics from a MetricReader
and VanillaPublicMetrics is deprecated. The MetricsEndpoint can now
exposes a collection of PublicMetric interface directly.
See gh-1094
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
This commit permits the use of several PublicMetrics instances by
default. Previously, only one PublicMetrics service could be specified
and a user configuration would remove all the defaulting.
VanillaPublicMetrics now takes a collection of PublicMetrics and
invokes them in sequence to build the final collection of metrics.
The system-related metrics have been moved to SystemPublicMetrics and
are registered by default.
Also updated the documentation to mention this feature and how it
could be fully overridden.
Fixes gh-1094
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
Add a Library class update the LibraryCallback interface and
implementations to use it. This change is in preparation for
an addition `unpack` flag that will be required to allow the
automatic unpacking of certain nested jars.
See gh-1070
Prior to this commit it was not safe to start several contexts
using the HornetQAutoConfiguration in the same VM. Each context
was trying to start their own HornetQ embedded broker by default but
only the first was really starting. Worse, the various InVM connection
factories were all silently connecting to the first broker.
This commit introduces a new "serverId" property that is an auto-
incremented integer by default. This identifies the server to connect
to and allows each context to start its own embedded broker in total
isolation of other contexts.
This commits makes it possible for a context to disable its own
embedded broker and connect to an existing one, potentially started
by another context.
Fixes gh-1063
Simplify the exclusion logic used in Gradle by implementing implicit
exclusions rather than trying to detect transitive excludes.
This commit reverts much of the code originally included to fix gh-1047
which adds far too much complexity to the build and still doesn't solve
the underlying issue.
Fixes gh-1103
The lists are comma separated. In addition, user can add prefixes
"+" or "-", to signal that those values should be removed from the
default list, not added to a fresh one. E.g.
$ spring jar app.jar --include lib/*.jar,-static/** --exclude -**/*.jar
to include a jar file specifically, and make sure it is not excluded,
and additionally not include the static/** resources that would otherwise
be included in the defaults. As soon as "+" or "-" prefixes are detected
the default entries are all added (except the ones exlcuded with "-").
Fixes gh-1090
- Log to the correct class
- Set Auto-configure after Thymeleaf hint on main class instead of
internal static class
- Use 'thymeleafViewResolver' bean name instead of class for
conditional bean checks
- Fix class name in properties documentation
Fixes gh-1052
I decided to go with both approaches (make the autoconfig for
repositories @ConditionalOnMissingBean(RepositoryFactoryBeanSupport),
so the first one wins; and also make them conditional on
spring.data.*.repositories.enabled=true. The ordering problem
is still there really (it's not defined which repositories will
be created by the autoconfig), so if a user is going to have
2 repository implementations on the classpath, he is going to
have to either choose one to disable, or manualy @Enable* the
other one.
Fixes gh-1042
Update Spring Mobile support with the following changes:
- Apply source formatting
- User lowercase property prefixes
- Use dashed notation when accessing properties
- Inline some constants
See gh-1049
@PropertySources *can* and should be added in the slot
after the application.properties (code that is part of the
application should have lower precedence than external
configuration).
Fixes gh-1044
They all want to create an MBeanServer and when that happens
user sees no MBeans, or sometimes just one set (Spring Core,
Spring Integration or Spring Boot). To harmonise them we
create a @Bean of type MBeanServer and link to it in the
other autoconfigs
Fixes gh-1046
This commit changes the default behavior of the HornetQ auto
configuration. Prior to this commit, an embedded broker was only
started when it was requested explicitly by a configuration option.
This is inconsistent with the ActiveMQ support and boot favors the
easiest route. If the necessary classes are available, HornetQ is
embedded in the application by default.
Fixes gh-1029
The list continuation character '+' can be used to prevent a blank
line from ending a list, thereby allowing code blocks to be included
in a list. See "Complex content in outline lists" [1] for more
details.
[1] http://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#listsFixes#1025
Not having READMEs in github is a mistake IMO, so here's one
restored and with a link to the docs. Docs also updated to
more accurately reflect the location of the actuator features
in implementation.
See https://github.com/spring-guides/gs-actuator-service/pull/7
for the Getting started guide change
Fixes gh-1014
Schema initialization now happens in @PostConstruct (effectively)
whether it is via the Hibernate EntityManagerFactory or the
Boot DataSourceInitialization (in addition or instead). The data.sql
script if it exists is still executed on an event fired from the
other places, so those tests are passing.
Flyway and liquibase have bean factory post processors (like
the one they use to order the audit aspect in Spring Data) that
enforce a dependency on those components from the EntityManagerFactory.
So Hibernate validation is still happy (and there are 2 tests to
prove it now as well).
Fixes gh-1022