Import DataSourcePoolMetadataProvidersConfiguration from
DataSourceAutoConfiguration so that PoolMetadataProviders are configured
even if actuator is not used.
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
if user also adds @EnableWebMvcSecurity. The problem is that the ordering
of the init() and configure() methods in the Spring Security configurers
can force things to happen too early unless we are careful. It's still a bit
twitchy I would say, but this relatively small change seems to fix the GS guide
and not break any existing tests.
I added a sample which mimic ths GS guide so we get an integration test that
executes the new code paths.
Fixes gh-1364
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
JSON output of /health now has the same structure for 1 or more HealthIndicators. This makes it easier to consume the response from scripts or apps
fixes#1291
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
Previously, when running on Java 7+, the JDBC query driven by
DataSourceHealthIndicator resulted in a call to
ResultSet.getObject(index, Object.class). When using MySQL's JDBC
driver this failed with an SQLException with the message "Conversion
not supported for type java.lang.Object". The problem does not occur
on Java 6 as the overload of getObject that takes a type does not
exist; ResultSet.getObject(index) is called instead and MySQL happily
returns whatever type it deems to be appropriate for the column.
This commit updates DataSourceHealthIndicator so that
ResultSet.getObject(index) will always be used, irrespective of the
version of Java that Boot is running on.
Closes#1306
Previously any custom http code mapping would remove the default mappings. With this commit the behaviour is changed so that default mappings will stay if a custom mapping is registered. Certainly a default mapping can be overridden.
fixes#1264
Previously any custom http code mapping would remove the default mappings. With this commit the behaviour is changed so that default mappings will stay if a custom mapping is registered. Certainly a default mapping can be overridden.
fixes#1264
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
In order to solve issues with multiple or incompatible AccessDecisionManagers, the CRaSH integration will now only delegate to an explicit shellAccessDecisionManager bean refs #1121
Prior to this commit, some tests were creating a parent/child
relationship but were only closing the child context. This could
be an issue with the autoconfig module as a lot of auto-config
kicks in by default.
This commit adds a new test utility designed to properly handle
those situations. Updated tests that were creating a context
hierarchy to benefit from that.
Fixes gh-1034
The Actuator endpoints ought to take precedence over others (since
they are important and users can isolate them using management.contextPath
if necessary). This change puts the @Order at -100 (well before the default
order of the RequestMappingHandlerMapping at 0).
Fixes gh-1107
To ensure an MBeanServer is available when needed you have to
look in JNDI before resorting to the JDK platform factory.
I had to copy some private code from Spring, but it seems
worth it.
Fixes gh-1092
Anywhere that an MBeanServer is needed it should be
created @Conditionally, so that user can exclude the
JmxAutoConfiguration and still get the other JMX
behaviours automatically.
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
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
Actually the web-secure sample is misusing
security.basic.enabled=false (IMO) - it should be a flag
to say that you want to temporarily disable the basic security
fallback on application endpoins, not way to disable all
security autoconfiguration.
Added test case to web-secure sample to ensure a user
can log in.
Fixes gh-979
Update Health and Status objects to be immutable, update the existing
builder methods to return new instances and add static convenience
methods to Health.
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.
Phillip Webb
Stephane Nicoll
Stephane Nicoll
Mattias Severson
Dave Syer
Christian Dupuis
Spring Buildmaster
Phillip Webb
Taylor Wicksell
Andy Wilkinson
Christian Dupuis
Dave Syer
Tobias Gesellchen
Andy Wilkinson
Eric Dahl
Lukasz Kryger
Tyler Frederick
sopov.ivan
Jakub Kubrynski
Nicholas Hagen
Rob Winch
Ben