To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
Move the @LocalServerPort to org.springframework.boot.context.embedded
since it's only really useful when working with embedded servlet
containers.
See gh-5822
Rework the new testing support so that @SpringApplicationTest can be
used for standard integration tests, web integration tests with a
mock Servlet environment and web integration tests with an embedded
servlet container. This means that it a replacement for 1.3's
@IntegrationTest and @WebIntegrationTest and allows all
SpringApplication testing to be configured using a common annotation.
The old @IntegrationTest and @WebIntegrationTest along with their
supporting classes have been reinstated to their previous form (while
remaining deprecated). This should ensure that they continue to work
in 1.4 exactly as they did in 1.3 giving users a smooth path to
@SpringApplicationTest.
See gh-5477
The commit adds a new BuildInfo task that can be used to generate
a build.properties file, intended for inclusion in the Actuator's
info endpoint.
A default instance of the task can be configure using the plugin's
DSL:
springBoot {
buildInfo()
}
Additional properties can also be configured using the DSL:
springBoot {
buildInfo {
additionalProperties = [
'foo': 'bar'
]
}
}
When configured via the DSL, the Java plugin's classes task is
configured to depend on the build info task. Alternatively, if more
control is required, the task can be declared and configured manually:
task buildInfo(type: org.springframework.boot.gradle.buildinfo.BuildInfo) {
additionalProperties = [
'foo': 'bar'
]
}
classes {
dependsOn buildInfo
}
See gh-2559
This commit updates the Maven plugin to generate a
`META-INF/boot/build.properties` file with various build-specific
settings (group, artifact, name, version and build time). Additionally,
the plugin can be configured to write an arbitrary number of additional
properties.
A new `BuildProperties` bean is automatically exposed when such a file is
present. If that bean is present, an `InfoContributor` is automatically
created to expose that information under the `build` key.
As for the git contributor, it is possible to only display the core
settings or everything using the `management.info.build.mode` property.
See gh-2559
`InfoProvider` is now `InfoContributor` and contributes to the `Info`
instance via a builder. The `Info` instance is immutable. Each
contributor can be disabled via the `management.info.<name>.enabled`
key or all can be disabled using `management.info.defaults.enabled` (this
is similar to what the health endpoint does).
By default, all keys from the environment starting with `info.` are
exposed. If a `git.properties` file is present in the classpath, the
content of `GitInfo` is exposed using the `git` key.
A `SimpleInfoContributor` and `AbstractEnvironmentInfoContributor` are
available for convenience. `InfoContributor` instances can be ordered
the usual way, with a default order provided by
`InfoProviderAutoConfiguration#DEFAULT_ORDER`.
Closes gh-3492
When `@EnableConfigurationProperties` is defined, Spring Boot
automatically registers a bean in the context for each class specified
on the annotation. Previously, the name of the bean only included the
prefix which leads to conflict if two different classes use the same
prefix.
This commit changes the bean name structure to be <prefix>-<fqn> where
prefix is the prefix used on the annotation and <fqn> the fully qualified
name of the target class.
Closes gh-4395
If user set the management.port *and* the management.context-path
then the /error path was in the wrong place because formerly it
was implemented (in this case) by an MvcEndpoint. If we
switch it to a regular @Controller (which are now supported in the
child context if there is one) then it won't disappear under the
management.context-path.
Also use lazy request matching in ignores as well as secure paths.
The problem was that the ignores were constructed eagerly from the
actuator paths before they were available (the EndpointHandlerMapping
needs to be lazily accessed to avoid a security-induced bean creation
cascade).
Fixes gh-4624
Update TraceWebFilter to optionally trace more details from the
HttpServletRequest/HttpServletResponse. The `management.trace.include`
property can be used to change what aspects are logged.
Closes gh-3948
Use "return" instead of "exit" where possible, especially in
function definitions.
Also fixed the exit codes to match the LSB spec for some specific
conditions (fixes gh-3521).
Fixes gh-3199, fixes gh-3535
Given that Spring Boot uses java config accross the board, a new `value`
attribute is now aliased to the existing `classes` attribute such that
one could write the following:
@SpringApplicationConfiguration(MyConfig.class)
public class MyTest {}
Closes gh-3635
There is a new spring.factories entry for
org.springframework.boot.actuate.autoconfigure.EndpointWebMvcConfiguration
which loads extra beans into the MVC config for the Actuator.
If the management context is a child context all the beans go in the
child (except the Spring Security filter still). A big bonus is that
you can add WebConfigurerAdapters to configure static resources etc.
A new component called ManagementContextResolver can be used to
locate the ApplicationContext for the MVC endpoints.
Fixes gh-3345
The default is now to reveal all details unless sensitive=true
(instead of only revealing then if sensitive was explicitly false).
The definition of "secure" also changes to something more sensible
where it is only true if security is enabled.
Fixes gh-2816
This reverts commit b1c0a7cda4.
The plugin publishing process has moved to a new plugin-based approach
that brings with it some significant limitations:
- There's no staging to allow the promotion of good release builds
- There's no easy way to upload an existing artifact
- There's no control over the published pom.
The risk brought by these limitations, particularly the first, are
too great so we will no be publishing the Boot plugin to the Portal
until they're resolved.
Changing the plugin's ID was a breaking change that would require
users to do some work when they upgrade to Boot 1.3. The ID of the
plugin was changed purely so that it met the Portal's requirements.
Given that the plugin will not be published to the Portal for the
foreseaable future there's no need for us to inflict a breaking change
on people when there will be no benefit.
See gh-1567
Gradle’s plugin portal requires each plugin’s ID to be in a namespace.
Our existing ID, spring-boot, does not meet this requirement. This
commit changes the plugin’s ID to org.springframework.boot.spring-boot.
Note that, as is recommended [1], the plugin’s ID does not include
“gradle”.
See gh-1567
[1] http://plugins.gradle.org/submit
Update ManagementSecurityAutoConfiguration so that MVC Endpoints that
have Principal arguments are not treated in any special way. This
restores Spring Boot 1.1.x behavior where the 'sensitive' flag is used
to determine access rules.
The HealthMvcEndpoint still uses the Principal (when available) to
determine if full status information can be displayed. It now also
explicitly checks the environment for `endpoints.health.sensitive`
to determine if the user has opted-out and requires complete health
details.
The health MVC endpoint should now work as follows:
* Default configuration - No login is required, full information is only
displayed if a Principal is available.
* endpoints.health.sensitive=true - Login is required, full information
is displayed.
* endpoints.health.sensitive=false - Login is not required, full
information is displayed.
Fixes gh-2211
Shares the /health endpoint request mapping between security config
and MVC dispatcher. Generalizes so that instead of a marker
interface (AnonymouslyAccessibleMvcEndpoint), an MvcEndpoint
signals that it wants to control its own access rules by adding
a Principal to the @RequestMapping method parameters (more @MVC).
Fixes gh-2015 slightly differently
The changes in 3bb598a overload the health endpoint's sensitive
property such that it's now considered sensitive if management
security is enabled. When an endpoint is sensitive anonymous
access is prevented. This breaks the health endpoint which should
return a filtered view of the server's health when it's accessed
anonymously rather than rejecting the request.
This commit introduces AnonymouslyAccessibleMvcEndpoint, a marker
extension of the MvcEndpoint interface. It is implemented by
HealthMvcEndpoint. ManagementSecurityAutoConfiguration has been
updated to allow anonymous access to endpoints that aren't sensitive
or that implement AnonymouslyAccessibleMvcEndpoint.
Fixes gh-2015
Including maps and lists. Beans with no metadata (in
/META-INF/*spring-configuration-metadata.json) are just serialized
as they come (so might have problems like cycles). Serialization
errors are caught and rendered as an "error" for that bean. Any
problems can be fixed by preparing metadata and specifying which
properties are to be rendered that way.
Fixes gh-1746, fixes gh-1921
The http.mappers.* configuration properties assumed that the mapping
was JSON (on of the property names was jsonPrettyPrint) and also only
exposed a small subset of the configuration options supported by
Jackson (and GSON). The property names implied that it would configure
all HTTP mapping, however it was ignored by GsonAutoConfiguration.
This commit deprecates the support for http.mappers.* in favour of
configuring Jackson or Gson instead. Jackson can be configured
declaratively using the spring.jackson.* properties or programtically.
Gson can be configured programatically by using a GsonBuilder to
create a Gson instance with the desired configuration.
gh-1946 has been opened to add support for declarative configuration
of Gson.
Closes gh-1945
It *is* very useful to have filtering on by default, so that is now
the case (in spring-boot-starter-parent). Users can filter resources
by default by adding @*@ placeholders (so as not to clash with Spring
${} placeholders).
Fixes gh-1199
Then we can optionally find a non-anonymous principal if there
is one. If the user is anonymous then the health result is cached
up to endpoints.health.ttl (default 1000ms) to prevent a DOS attack.
Fixes gh-1353
If the actuator endpoints are configured on a different port then there
are some settings in the main ServerProperties that we would like to
re-use (e.g. the access log). The easiest way to do that is to just
configure the management server using the same ServerProperties instance
and then overwrite the things that are different (and stored in
ManagementServerProperties).
Fixes gh-1581
The request is being made to '/' and, while the application does have
a mapping for '/', that mapping is not looked for before Spring
Security's filter rejects the request with a 401. This means that the
request is considered to be unmapped and this is reflected in the
metric's name.
See #1331 and #1333
With this commit the state of a component or subsystem becomes a first-class citizen in Boot's application health support. HealthIndicators now return a Health instance with status and some contextual details.
An aggregation strategy has been introduced to aggregate several Health instances into one final application Health instance. Out of the box OrderedHealthAggregator can be configured to allow different ordering or a custom HealthAggregator bean can be registered.
We now have a much simpler DataSourceAutoConfiguration that binds to whatever
DataSource concrete type it finds at runtime. To be able to quickly switch between
Hikari and the other types of DataSource there's a minute shim for translating
the common properties (username, password, url, driverClassName), but actually
only url is different. The shim and also DataSource initialization is supported
through DataSourceProperties, but the other native properties get bound directly
through the concrete runtime type of the DataSource.
The /configprops endpoint works (and is exposed in the actuator sample).
Fixes gh-840, fixes gh-477, see also gh-808.
Since Spring supports gobal error handling through
@ControllerAdvice, it is quite easy to set up more meta-data
about an exception for the BasicErrorController. You need
to be careful not to swallow Security exceptions, and probably
others (optionally) so this feature needs a bit more work.
See gh-538
Spring Security doesn't know that Spring MVC maps /foo, /foo.json
and /foo/ all to the same handler. This change explicitly adds
suffixes to the actuator endpoint matchers so they are properly
protected.