You can contribute additional HttpMessageConverters
by simply adding beans of that type in a Spring Boot
context. If a bean you add is of a type that would have been included
by default anyway (like MappingJackson2HttpMessageConverter for JSON
conversions) then it will replace the default value. A convenience
bean is provided of type MessageConverters (always available if you
use the default MVC configuration) which has some useful methods to
access the default and user-enhanced message converters (useful, for
example if you want to manually inject them into a custom
RestTemplate).
There are also some convenient configuration shortcuts for Jackson2.
The smallest change that might work is to just add beans of type
Module to your context. They will be registered with the default
ObjectMapper and then injected into the default message
converter. In addition, if your context contains any beans of type
ObjectMapper then all of the Module beans will be registered with
all of the mappers.
Previously if a user happened to provide an @EnableWebSecurity bean
the SecurityProperties would not be created, which is fine until you
add the Actuator (which needs them). Fixed by adding an explicit
SecurityProperties @Bean if not already present.
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).
ServerProperties formerly had an @OnMissingBeanCondition
that didn't restrict the hierarchy. It also asserts that
the current context (not including parents) contains such
a bean. This led to an inevitable failure when there was
an existing instance in the parent context.
Fixed by a) searching only the current context, b) not
adding a ServerProperties bean if the context is not a
web app.
In case Spring Security is missing from the class path, shell auto configuration will now fall back gracefully to simple authentication and emit warning to the console.
fixes#114
Now simple authentication for the crsh shell can we configured using shell.auth.simple.user.name and shell.auth.simple.user.password. This is consistent with security.user.name and security.user.password.
fixes#113
In case a Spring Security AuthenticationManager is found in the app context the auto configuration will change default shell authentication method to auth against Spring Security. In addition shell access will get protected by the specific role configured in SecurityProperties.Management.
Certainly this can be overridden by providing shell.auth and shell.auth.spring.roles.
Fixed inconsistency in method naming after last polish. Method and class name should use 'crsh' instead of 'crash' to be aligned with CRaSH code base.
Implemented facility to provide custom shell properties by adding beans of type CrshShellProperties to the ApplicationContext.
Update the auto-configuration report to improve log formatting and to
separate the internal report data-structure from the JSON friendly
endpoint data-structure.
- Gather autoconfiguration conditional decisiions (true and false)
- Provide an actuator endpoint as one means to read the report
- Define @EnableAutConfigurationReport annotation to turn this feature on
- Tidy up autoconfig report a bit and log it if --debug=true
This commit adds a new starter named spring-boot-starter-shell-crsh and auto configuration support to embed a system shell within Spring Boot applications.
The embedded shell allows clients to connect via ssh or telnet to the Boot app and execute commands. Commands can be implemented and embedded with app.
For sample usage see spring-boot-samples-actuator.
Previously the management endpoint filter was applied to all requests
if the user had disabled security.management.enabled, but since it
had no security applied it was letting all requests through.
The fix was to explicitly exclude the whole enclosing configuration
and carefully ignore the management endpoints in the normal security
chain.
Fixes gh-100.
Builder for SpringApplication and ApplicationContext instances with
convenient fluent API and context hierarchy support. Simple example
of a context hierarchy:
new SpringApplicationBuilder(ParentConfig.class)
.child(ChildConfig.class).run(args);
Another common use case is setting default arguments, e.g.
active Spring profiles, to set up the environment for an application:
new SpringApplicationBuilder(Application.class).profiles("server")
.defaultArgs("--transport=local").run(args);
If your needs are simpler, consider using the static convenience
methods in SpringApplication instead.
[#49703716] [bs-116] Parent context for some beans maybe?
username/password pairs were incorrect. The authentication manager has "user" and "password", so those credentials should be allowed to get the actual message.
If the user sets security.basic.enabled=false we should just
back away from the non-management endpoints completely.
Previously the Spring Security filter was still added but with
no authentication, creating complications when unexpected
headers etc. are added by Spring Security.
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]
Management endpoints are still secure by default if
Spring Security is present, but now the default
user details have an ADMIN role, and a random password
(which is logged at INFO level if not overridden).
To override you add management.user.password (name, role)
to external properties.
[Fixes#53029715] [bs-203]
* 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
Rework main build POM to be an aggregator pom that does not inherit
from any parent. Introduce new spring-boot-dependencies module to
act as a parent for both spring-boot-starter-parent and
spring-boot-parent.
