The in-memory version has to force the incoming metric keys to
start with the group name. Redis doesn't have that restriction
but normally we expect both to be used in such a way that
the metric keys already match the prefix. In that case the two
repositories behave the same now in terms of set and get.
In the redis repository we also switch to store the value in the
zset (so it can be atomically incremented) rather than in the
regular key-value.
Fixes gh-929
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.
The prefix needs to be added before looking for keys. In addition
I rationalized the constructor and final fields (it didn't make
any sense for the prefix to be mutable).
Fixes gh-927
The PrefixMetricGroupExporter only really makes sesne if the writer
is aware of the groups, so it seemed better to use a new interface
than mix read/write.
Update all @PostConstruct methods to ensure that they don't throw
checked exceptions. Required to allow deployment of Spring Boot
applications on Glassfish.
Fixes gh-868
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.
Introspects the properties that are being exposed in the report
and only renders the ones that are a) convertible from String
and b) have a setter. That goes a long way to making it a bullet
proof generic renderer of any Java object that can be bound with
@ConfigurationProperties.
Update the BasicErrorController so that it no longer needs to implement
@ControllerAdvice or have an @ExceptionHandler method.
A new ErrorAttributes interface is now used to obtain error details,
the DefaultErrorAttributes implementation uses a
HandlerExceptionResolver to obtain root exception details if the
`javax.servlet.error.*` attributes are missing.
This change also removes the need for the extract(...) method on
ErrorController as classes such as WebRequestTraceFilter can
now use the ErrorAttributes interface directly.
See gh-839, gh-538
Fixes gh-843
For the convenience of users who want to selectively override the
access rules in an application without taking complete control of the
security configuration we now have some constants:
* SecurityProperties.ACCESS_OVERRIDE_ORDER for overriding just the
application endpoint access rules
* ManagementServerProperties.ACCESS_OVERRIDE_ORDER for overriding the
application endpoint and management endpoint access rules
Fixes gh-803
Refactored HealthEndpoint to be able to take multiple HealthIndicators. Extracted configuration of HealthIndicators out of EndpointAutoConfiguration and added new HealthIndicatorAutoConfiguration class.
Added HealthIndicators for Redis and Mongo.
This commit harmonizes the dependency management of internal modules
so that versions can be omitted everywhere. Update the maven coordinates
to provide the full groupId for consistency
Two modules are still relying on the spring-boot test-jar but it was
not generated anymore. Adding the generation of test-jar again as
a workaround until we completely removes the use of it.
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
Salvatore has indicated that Jedis is his Java Redis client of choice.
This commit updates the auto-configuration support, actuator and
Redis starter accordingly.
Completes #745
Reverting arguments in assertEquals where constant was placed on
the "actual" place. Replacing assertEquals with assertFalse, assertTrue
and assertNull where applicable.
Fixes gh-735
Remove the mutable getEmbeddedServletContainers() Map from
EmbeddedWebApplicationContext and instead use the `namespace` to
distinguish the management container.
The ServerPortInfoApplicationContextInitializer class replaces the
previous TestExecutionListener to exposes port properties (by
listening for EmbeddedServletContainerInitializedEvents).
When mapping the ErrorController path to Spring Security it's
important that it starts with "/". This change ensures that is
the case even if the user has omitted the leading "/".
Fixes gh-694
When the user sets management.contextPath=/admin the Jolokia
endpoint gets mapped to /admin/jolokia, but that the path stripper it uses
internally makes a false assumption about the form of the request path.
The fix is simple (just use a smarter search for the endpoint path in the
request path).
Fixes gh-642
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.
The management security autoconfiguration wanted to come last in the chain
but that won't suit the fallback that was already in place for gh-568. This
change re-orders the autoconfig so that @EnableWebSecurity is still added
if the user sets security.basic.enabled=false and includes the actuator
endpoints.
Fixes gh-568
We can't support (yet) embedded containers inside a deployed war (class
loader conflicts are inevitable, really). Until we figure out a way to
do it, we should just log a warning and advise the user to switch to
JMX for the actuator endpoints.
See gh-552
Remove README files that have been since been migrated to the reference
documentation. Also updated remaining markdown files to asciidoctor to
save having a mix of different formats.
Fixed gh-503
The management.contextPath property should now be respected in a
secure application, whether or not the management.port is different.
Added some test cases in the sample to verify.
Fixes gh-469
Rename ConfigurableEmbeddedServletContainerFactory to
ConfigurableEmbeddedServletContainer and extract
AbstractConfigurableEmbeddedServletContainer from
AbstractEmbeddedServletContainerFactory.
There's no explicit support for older Servlet specs in Spring Boot,
but we can at least make it easy for others to provide such
support by not adding stuff to the context when in an older container.
Some assumptions were being made in tests, e.g. about
there being an AuthenticationManager @Bean, which were
false with the new Security 3.2.1 updates from Rob.
Also parent-child contexts with the actuator were
problematic because they didn't exclude the web configuration
for the management security in the parent context.
Fixes gh-244
Also change strategy for defaulting of Authentication. Spring
Boot authentication defaults are now encapsulated and can easily
be overridden by a user defined AuthenticationManager.
Error pages are a feature of the servlet spec but there is no Java API for
registering them in the spec. This filter works around that by accepting error page
registrations from Spring Boot's EmbeddedServletContainerCustomizer (any beans
of that type in the context will be applied to this container).
In addition the ErrorController interface was enhanced to provide callers
the option to suppress logging.
Fixes gh-410
The default executor for publishing metrics was a single
thread (native JDK) ExecutorService with a non-daemon thread.
Changed it to a Spring-managed thread pool of size 1, which
is then shutdown with e ApplicationContext automatically.
Fixes gh-388
Update `EndpointWebMvcAutoConfiguration` to use '-1' to indicate that
the management context should be disabled. This brings consistency
between the server settings and the management settings and allows '0'
to be used to pick a random port.
Fixed gh-311
Spring Boot provides a default AuthenticatiomManager for getting
started quickly with security and never exposing insecure
endpoints. To override that feature as users move to the next
stage in their project, they may have to do something slightly
different depending on whether it is a webapp or not.
In any app (web or not), providing a @Bean of type
AuthenticationManager always works, but you don't get the benefit of
the builder features.
In a webapp the user can also extend WebSecurityConfigurerAdapter
to provides a custom AuthenticationManager, and the preferred
way of doing that is via a void method that is autowired with an
AuthenticationManagerBuilder. The default AuthenticationManager is
built in a configurer with @Order(LOWEST_PRECEDENCE - 3) so
to override it the user's confugrer must have higher precedence
(lower @Order).
@EnableGlobalMethodSecurity can also be used in a non-webapp, and
Spring Boot will still provide a default AuthenticationManager.
To override it the user has to either extend
GlobalMethodSecurityConfiguration or provide a @Bean of type
AuthenticationManager (there's no other way to
capture the AuthenticationManagerBuilder that doesn't happen too late
in the beans lifecyle).
Fixes gh-244
If the context hierarchy is from a SpringApplication we can control
the shutdown semantics a bit. Specifically we need a listener in the child context
that will shut it down when the parent closes (since assummably the child relies
on beans in the arent that may now be disposed).
Fixes gh-275
Upgrade to Tomcat 7.0.50, working around the potential
NullPointerException by also adding dependencies to
tomcat-embedded-jasper (which is now also required for Hibernate
Validator 5.0, see commit 377953babd)
Fixes gh-245
Instead of adding active prpfiles for every one we encounter, we need to
build up a complete "default" Environment and then ask it what the active
profiles are. Implemented in ConfigFileApplicationListener.
Fixes gh-198
Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).
MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.
There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).
In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).
Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.
Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.
No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.
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.
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.
Phillip Webb
Andy Wilkinson
Christian Dupuis
Dave Syer
Lukasz Kryger
Stephane Nicoll
Tyler Frederick
sopov.ivan
Spring Buildmaster
Jakub Kubrynski
Nicholas Hagen
Rob Winch
Ben
Greg Turnquist
ggerard
lecaros
checketts
Phillip Webb