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.
* Underscores are allowed as nested property field separators
* System and env vars are only considered for binding if they
look like they apply to a given bean when ignoreUnknownFields
is false
@ConfigurationProperties(ignoreUnkownFields=false,ignoreNestedFields=true)
is now a useful option for binding to "top-level" command line options
(without a prefix). In that case we don't try to bind to `server.*` and
other common prefixed property values (at the cost of not being able to
bind to nested beans).
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.
If the server port is 0 it doesn't mean you don't want *any* container
because there might still be servlet context aware components in the
classpath. Better to try and stop the server from actually starting.
This change is a step in the right direction: it prevents the server
from starting in the start() method (even though for technical reasons
it may have already been started and stopped in initialize()).
N.B. Tomcat at least uses port=0 as a signal it should pick a random
port. Pertty useful feature that we may want to capitalize on at some
point (on the other hand having our own port scanner would be useful
generally too).
When a PropertySourcesPropertyValues is used to bind Environment
values to a bean (or the SpringApplication) it tries to resolve
placeholders eagerly in the Environment. Any that fail might not
actually be a problem for users (until validation is done it's
impossible to tell even whether that value was needed for the
ongoing binding or not).
Fixed by ignoring exceptions in the PropertySourcesPropertyValues
constructor.
Fixes gh-108
RelaxedDataBinder now supports "env var" style variables that include the
path prefix, e.g. FOO_BAR_BAZ=boom will bind to a bean with property "baz"
and a binder with prefix "foo.bar".
Fixes gh-98
Dave Syer
Phillip Webb
Christian Dupuis
nitram509
Andy Wilkinson
Andreas Kluth