If two auto-configuration classes with the same name are present,
the conditions report message now uses the fully qualified name for
both instead of the short name.
Fixes gh-11710
Update micrometer auto-configuration so that a `CompositeMeterRegistry`
is only created when more than one `MeterRegistry` bean is declared.
When a composite is crated, it is marked as `@Primary` so that it
can be directly injected. Meter registries can now be defined directly
as beans, and auto-configuration can back off in the usual way.
The `MeterRegistryConfigurer` is now called `MeterRegistryCustomizer`
and is generically types so it's easy to apply customizations to a
particular `MeterRegistry` implementation.
Fixes gh-11799
Co-authored-by: Jon Schneider <jschneider@pivotal.io>
Move projects to better reflect the way that Spring Boot is released.
The following projects are under `spring-boot-project`:
- `spring-boot`
- `spring-boot-autoconfigure`
- `spring-boot-tools`
- `spring-boot-starters`
- `spring-boot-actuator`
- `spring-boot-actuator-autoconfigure`
- `spring-boot-test`
- `spring-boot-test-autoconfigure`
- `spring-boot-devtools`
- `spring-boot-cli`
- `spring-boot-docs`
See gh-9316
Previously, the configuration class that produces the ErrorPageFilter
bean was an inner class of SpringBootServletInitializer. As a result,
whenever SpringBootServletInitializer was subclasses, the
ErrorPageFilter would be used. This adversely affected applications
running as an executable war file and those deployed to a container
with error page filter registration disabled.
This commit makes ErrorPageFilterConfiguration a top-level class so
that it is no longer always found via SpringBootServletInitializer.
The test that verifies that error page filter registration can be
disabled has been updated to more accurately simulate the behaviour
when an application is deployed as a war to a standalone container.
A test that mimics the behaviour of an application run as an
executable war has also been added.
Closes gh-8477
Previously, if an auto-configuration class was (wrongly) located in a
candidate package for component scanning, the class was silently loaded
as an app configuration (i.e. with the wrong lifecycle).
This commit adds an `AutoConfigurationExcludeFilter` to
`@SpringBootApplication` so that such classes are automatically
filtered. Since they are registered in `spring.factories`, we can
silently ignore them since we know they'll be loaded later on.
Closes gh-7168
Add TestTypeExcludeFilter which will automatically attempt to exclude
test only configurations. All `@Configuration` annotated inner-classes
of tests are automatically excluded. The `@TestConfiguration` annotation
can be used to explicitly if a configuration needs explicit exclusion.
See gh-5295
See gh-4901
Add a new TypeFilter specifically for excluding candidate components.
The filter is applied to `@SpringBootApplication` and allows tests to
dynamically contribute exclude filters so that specific classes of
component can be excluded.
See gh-5295
See gh-4901
This commit introduces a new failure analyser for
NoUniqueBeanDefinitionException. The analyser provides details of the
consumer whose dependency could not be satisfied and the names and
sources of the non-unique beans.
This analysis requires access to the BeanFactory, so FailureAnalyzers
has been updated to support BeanFactory injection via an analyzer
implementing BeanFactoryAware.
Closes gh-5299
Add ConfigurationWarningsApplicationContextInitializer to report
warnings for common configuration mistakes. Currently the initializer
will log a warning if @ComponentScan is used on a @Configuration class
in the "default" package.
Fixes gh-2050
Phillip Webb
Scott Frederick
Madhura Bhave
Phillip Webb
Andy Wilkinson
Stephane Nicoll
Dave Syer