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 it was @ConditionalOnMissingBean(CommandLineRunner.class)
which caued obvious problems when user wanted to add an unrelated
CLR.
Extended feature set so that a JobRegistry can also be used (with
spring.batch.job.name) and the whole idea can be switched off with
spring.boot.job.enabled.
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.
Previously all EventListeners were eagerly instantiated
but that can cause problems because it happens quite early
in the lifecycle. Better to be explicit about the
supported types.
This leverages existing capabilities of teh JDK and the OS
to grab a port at random and not have it stolen by another
process. It's very hard to avoid that race condition in
pure Java code, so why bother?
User can set port<0 to disable autoStart of connectors (e.g.
to start a web application context but not have it listen on
any port). In that case the actual socket port will be set to
0 (and therefore if it ever starts up the local port will
be random).
The AutoConfigurationReportLoggingInitializer wasn't working in
non-GenericApplicationContext becasue teh BeanFatcory wasn't available
for registering its listener during initialization. Instead of
relying on that rather fragile state I decided to give any
ApplicationContextInitializer that was itself an ApplicationListener
an explicit callback with a ContextRefreshedEvent, and move that
interface up a level in the logging initializer. Works much better.
Using containsBean() involves looking in the parent bean factory
if there is one, and that would mean that the same report woykd be used
for multiple contexts, which wouldn't make sense.
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
To use a DataSource pool (Tomcat or DBCP) the user must supply a valid
driver class name *and* database URL. If both are supplied and the
driver class is not one of the embedded ones, then no default username
or password is provided.
Fixes gh-94
Use of hasMappingForPattern was commented out during work on the
Aether-based Grape implementation as it was temporarily removed in
Spring 4's snapshots. It's since been reinstated in the snapshots, so
its use should have been reinstated prior to merging Aether work into
master.
Previously, @Grab annotations would use Ivy to download the
dependencies with some of Ivy's known limitations being worked around
by GrapeEngineCustomizer.
This commit adds a GrapeEngine implementation that uses Aether,
the dependency resolution 'engine' used by Maven and Grails. To ensure
consistent behaviour with a Maven build, the Aether-powered dependency
resolution uses the dependency management configuration from the
spring-boot-starter-parent pom file.
Since ServerProperties had primitive properties for port (in
particular) it was not possible to check when applying those
properties if the user had actually changed the value. This
in turn meant that a custom EmbeddedServletContainerFactory
could not set the default values.
Fixed by making int properties of ServerProperties into
Integer and checking for null before setting on the
container factory.
Fixes gh-84
Dave Syer
Christian Dupuis
Phillip Webb
Greg Turnquist
Andy Wilkinson
Roy Clarkson