Previously, BasicErrorController would return the response status
set in the javax.servlet.error.status_code request attribute when
serving JSON but would also return a 200 OK response when serving
HTML. This didn’t cause much trouble when a person was browsing, but
proved problematic for machine clients that request text/html and care
about the response status. For example, the success handler would be
driven for an XHR request even though the response was really an error.
This commit updates BasicErrorController to set the response status for
text/html responses to match the status that it would use in an
application/json response.
Closes gh-4694
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
Rename `VanillaHealthIndicator` to `ApplicationHealthIndicator` and
changed the exposed bean name from `statusHealthIndicator` to
`applicationHealthIndicator`.
This provides less confusing JSON output:
{"status":"UP","application":{"status":"UP"}}
vs:
{"status":"UP","status":{"status":"UP"}}
Fixes gh-1291
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.
Rename the RestTemplates to TestRestTemplate to help indicate that it's
primarily intended for testing. Also now extend RestTemplate to allow
direct use, rather than via factory methods.
Fixes gh-599
Makes them a lot more readable IMO, and also enables @Autowiring
from the context into the test case (sweeet). I added @DirtiesContext
to all of them as well to be on the safe side, but possbly that can be
optimized in some way as well.
Use org.springframework.boot instead of ${project.groupId}
groupId in order to make it easier to use spring-boot-samples
modules as a starting point for new projects.
Long package names are really unnecessary in samples and they
just clutter things up. Also Spring Loaded doesn't work with
org.sfw packages, so to demo that technology you need a
different package name.
We get more control over the handling and in particular the registration
of the endpoint this way. It was practically impossible to disable the
AgentServlet bean when in a parent context of the management server
because of lifecyce issues - you don't know that the user wants a
separate management server until too late.
This approach also makes it possible to test with spring-test MVC
support.
When management endpoints are on a different port the HandlerMappings
are restricted to a single EndpointHandlerMapping, so the error
controller (which is a normal @Controller with @RequestMappings) does
not get mapped.
Fixed by addinga shim Endpoint on "/error" that delegates to the
ErrorController (which interface picks up an extra method).
Remove '/resources/**' mapping since it can cause problems with the
'/**' when the developer defines their own 'resources' sub-folder.
Also remove default servlet config since the resources mapping renders
it redundant.
Issue: #55494446
The management endpoints were still all mixed up
with the user endpoints. Fixed that and extracted
user endpoints in to conditional block so not
protected if path explicitly set to empty string.
[#53029715]
* Add integration tests for /error view
* Add "error" @Bean as default view for HTML
Users may see side effects because now there will be
a ContentNegotiatingViewResolver by default for the
first time in a vanilla Actuator app. Should be
interesting.
[Fixes#54597932] [bs-273] Circular view reference for /error
