User can now do this, for instance:
@Configuration
@PropertySource("classpath:my.properties")
public class MainConfiguration {}
@Configuration
@PropertySource("classpath:foo.properties")
@Profile("foo")
public class FooConfiguration {}
and the "foo" properties ar eonly loaded in the "foo" profile.
If any of the sources has a @PropertySource annotation (or many)
then we can add those properties to the Environment. It's a nice
convenient way of specifying a custom external properties location
for an app.
One problem is that Spring will come along and parse the same
annotations later as part of the @Configuration parsing. The
user has pretty limited control over how that is done, and it
will never be done in a "natural" way for a Boot application
(which would prefer that the default application.properties
is applied *last*, whereas Spring will apply the @PropertySource
last).
To get round that problem we add the property sources with
a different name (key in the PropertySources in Environment),
prefixing named property sources with "boot.", and adding
others with a name that is the same as the resource location
(instead of its description, which is the default for
Spring).
Another problem is that Spring doesn't know about YAML, so
the user is currently restricted to using properties files
with this annotation.
We still need the distinction internally between initial and additional
sources, but the SpringApplication API (getSources()) itself doen't
need to reflect that.
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.
User can add (a single) beans{} DSL declaration (see GroovyBeanDefinitionReader
in Spring 4 for more detail) anywhere at the top level of an application source
file. It will be compiled to a closure and fed in to the application context
through a GroovyBeanDefinitionReader. Cool!
The example spring-boot-cli/samples/beans.groovy runs in an integration test
and passes (see SampleIntegrationTests).
Reinstate initializeWithSensibleDefaults() on AbstractLoggingSystem
beforeInitialize(). This is required to ensure no superfluous logging
output occurs when starting up a spring boot application from the
command line.
It appears that commit e9c649dfb2
modified the logic in an attempt to prevent double initialization.
fixes gh-174
Dave Syer
Guo Du
Phillip Webb
Christian Dupuis
Spring Buildmaster