Previously EmbedddedContainerConfiguration cannot be imported directly.
This change ensures that the nested classes are not loaded automatically
so there can be no issues with the annotation parameters.
There might be a case for a change in Spring here since the framework
itself could just be more cautious when processing nested classes.
[Fixes#50880927]
Various parent context topologies are tried to ensure that the properties
are bound sensibly.
[#50804109] Allow @ConfigurationProperties beans to be declared
explicitly (to set default values)
User adds @OnManagementContext to a bean or @Configuration and
it should be included in the management context (if there is one)
whether it is the main context or a child.
Makes it easy to secure the management endpoints and keep
the rest open (see actuator-ui-sample).
[#50721675]
* The RegistrationBean (ServletInitializer) now exposes a registration
target object, and this is used to prevent double registration of those
objects.
* If there is a Servlet with bean id "dispatcherServlet" it is mapped to
"/" (unless already registered as a ServletRegistrationBean).
[Fixes#48645559]
* A simple check to see if it is already registered
fixed the original problem
* Also removed the need to have @ConfigurationProperties
on a bean class (unless you want to specify the target name
etc.)
[Fixes#50256421] [bs-130] When actuator app starts the
@ConfigurationProperties are registered with the bean
factory several times
* If the auto config class has a high Order it can check for
an existing transaction manager
* Unit tests added, and checked also witrh petclinic
[Fixes#50064347]
* If Tomcat jdbc is available and the driverClassName and url
are provided or can be guessed (e.g. for HSQL) it is used.
Properties spring.database.{driverClassName,url} are consulted.
* If Commons DBCP is available it is used (if Tomcat is not)
* Otherwise an EmbeddedDatabase is created if all the bits are
available
* A JdbcOperations and a NamedParameterJdbcOperations are
available by default if a DataSource is created
* The data source is initialized from spring.database.schema (csv
of resource patterns)
[Fixes#49393511]
* Extracted the component scan detector so it can be used
without @EnableAutoConfiguration
* Added unit tests
* Improve logging in @Conditional processing
[#48127729]
* MessageSource created automatically (location
spring.messages.basename:messages)
* Thymeleaf configured automatically to look for
templates in classpath:/templates
* Added static resource handlers for classpath:/static
and classpath:/
[Fixes#49832165] [bs-118] Support for thymeleaf templates
* All instances are called before the container is started in
a bean post processor
* Users still have to be careful because the customizer is
called very early in the ApplicationContext lifecycle (e.g.
might have to do a lookup for some dependencies instead of
@Autowired)
[Fixes#49671463] User-hook for customizing embedded servlet container
It's not really a security feature (just logging request headers),
so better to put it in the main actuator autoconfig.
[Fixes#49578819] [bs-111] Unresolvable cycle when separating management.port
Update JavaLoggerConfigurer to use the ApplicationContext classloader
rather then the default classloader. Also refactored to introduce
LoggingSystem enum to act as a strategy for the specific logging
systems.
* ManagementProperties and ServerProperties now support an address property
* For example set management.port=9001,management.address=127.0.0.1 to listen
on port 9001 but only for connections from the localhost
[Fixes#49395783]
* If git.properties is on the classpath (e.g. from the Maven plugin)
/info will list the commit id, branch and dates.
* If application.yml has an info object at the top level that will
be diplayed as well (so e.g. you can use Maven resource filtering
top add the project name, version etc.)
* RelaxedDataBinder can now be used to bind to a Map (as opposed to
a nested Map inside teh target bean)
[Fixes#49130073]
Dave Syer
Phillip Webb