and read from there the available external configuration
@ -27,16 +27,16 @@ Javadocs. Some rules of thumb:
@@ -27,16 +27,16 @@ Javadocs. Some rules of thumb:
acts as a prefix to external properties, thus `ServerProperties` has
`name="server"` and its configuration properties are `server.port`,
`server.address` etc.
* Look for use of `RelaxedEnvironment` to pull configuration values
explicitly out of the `Environment`. It often is used with a prefix.
* Look for `@Value` annotations that bind directly to the
`Environment`. This is less flexible than the `RelaxedEnvironment`
approach, but does allow some relaxed binding, specifically for OS
environment variables (so `CAPITALS_AND_UNDERSCORES` are synonyms
for `period.separated`).
* Look for `@ConditionalOnExpression` annotations that switch features
on and off in response to SpEL expressions, normally evaluated with
placeholders resolved from the `Environment`.
@ -84,7 +84,7 @@ In addition, if your context contains any beans of type `ObjectMapper`
@@ -84,7 +84,7 @@ 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. So there is a global mechanism for contributing custom
modules when you add new features to your application.
Finally, if you provide any `@Beans` of type
`MappingJackson2HttpMessageConverter` then they will replace the
default value in the MVC configuration. Also, a convenience bean is
@ -173,7 +173,7 @@ public EmbeddedServletContainerCustomizer containerCustomizer(){
@@ -173,7 +173,7 @@ public EmbeddedServletContainerCustomizer containerCustomizer(){
@ -190,7 +190,7 @@ public EmbeddedServletContainerCustomizer containerCustomizer(){
@@ -190,7 +190,7 @@ public EmbeddedServletContainerCustomizer containerCustomizer(){
connector.setAttribute("clientAuth", "false");
connector.setAttribute("sslProtocol", "TLS");
connector.setAttribute("SSLEnabled", true);
});
}
}
@ -256,7 +256,7 @@ Create a deployable WAR by extending `SpringBootServletInitializer`
@@ -256,7 +256,7 @@ Create a deployable WAR by extending `SpringBootServletInitializer`
@EnableAutoConfiguration
@ComponentScan
public class Application extends SpringBootServletInitializer {
@ -478,7 +478,7 @@ will see that it uses some useful System properties which the
@@ -478,7 +478,7 @@ will see that it uses some useful System properties which the
* `${LOG_FILE}` if `logging.file` was set in Boot's external configuration
* `${LOG_PATH` if `logging.path` was set (representing a directory for
log files to live in)
Spring Boot also provides some nice ANSI colour terminal output on a
console (but not in a log file) using a custom Logback converter. See
the default `base.xml` configuration for details.
@ -626,7 +626,7 @@ algorithm for choosing a specific implementation.
@@ -626,7 +626,7 @@ algorithm for choosing a specific implementation.
* If neither of those is available but an embedded database is then we
create one of those for you (preference order is h2, then Apache
Derby, then hsqldb).
The pooling `DataSource` option is controlled by external
configuration properties in `spring.datasource.*` for example:
@ -742,7 +742,7 @@ Properties from different sources are added to the Spring
@@ -742,7 +742,7 @@ Properties from different sources are added to the Spring
`Environment` in a defined order, and the precedence for resolution is
1) commandline, 2) filesystem (current working directory)
`application.properties`, 3) classpath `application.properties`. To
modify this you can provide System properties (or environment variables)
modify this you can provide System properties (or environment variables)
* `config.name` (`CONFIG_NAME`), defaults to `application` as the root
@ -57,7 +57,7 @@ public class ConfigurationPropertiesReportEndpoint extends
@@ -57,7 +57,7 @@ public class ConfigurationPropertiesReportEndpoint extends
Assert.notNull(keysToSanitize,"KeysToSanitize must not be null");
this.keysToSanitize=keysToSanitize;
}
@ -69,10 +69,10 @@ public class ConfigurationPropertiesReportEndpoint extends
@@ -69,10 +69,10 @@ public class ConfigurationPropertiesReportEndpoint extends
@ -94,7 +94,7 @@ public class ConfigurationPropertiesReportEndpoint extends
@@ -94,7 +94,7 @@ public class ConfigurationPropertiesReportEndpoint extends
Then access the app via a browser (or curl) on http://localhost:8080 (the user name is "user" and look at the INFO log output for the password to login).
Then access the app via a browser (or curl) on http://localhost:8080 (the user name is
"user" and look at the INFO log output for the password to login).
The gradle build contains an intentionally odd configuration to exclude the security dependencies from the executable JAR. So the app run like this behaves differently than the one run from the Maven-built JAR file. See comments in the `build.gradle` for details.
The gradle build contains an intentionally odd configuration to exclude the security
dependencies from the executable JAR. So the app run like this behaves differently than
the one run from the Maven-built JAR file. See comments in the `build.gradle` for details.
@ -70,7 +70,7 @@ is intended to be run as it is you need to have all dependencies in it, however
@@ -70,7 +70,7 @@ is intended to be run as it is you need to have all dependencies in it, however
if a plan is to explode a jar file and run main class manually you may already
have some of the libraries available via `CLASSPATH`. This is a situation where
you can repackage boot jar with a different set of dependencies. Using a custom
configuration will automatically disable dependency resolving from
configuration will automatically disable dependency resolving from
`compile`, `runtime` and `provided` scopes. Custom configuration can be either
defined globally inside `springBoot` or per task.
@ -131,7 +131,7 @@ sources jars are automatically skipped).
@@ -131,7 +131,7 @@ sources jars are automatically skipped).
Because on default every repackage task execution will find all
created jar artifacts, the order of Gradle task execution is
important. This is not going to be an issue if you have a normal
important. This is not going to be an issue if you have a normal
project setup where only one jar file is created. However if you are
planning to create more complex project setup with custom Jar and
BootRepackage tasks, there are few tweaks to consider.
@ -149,7 +149,7 @@ out from your project. You could also just disable default
@@ -149,7 +149,7 @@ out from your project. You could also just disable default
bootRepackage.withJarTask = jar
```
Above example simply instructs default `bootRepackage` task to only
work with a default `jar` task.
work with a default `jar` task.
```groovy
@ -165,6 +165,6 @@ create dependency to your build so that `bootJars` task would
@@ -165,6 +165,6 @@ create dependency to your build so that `bootJars` task would
be run after the default `bootRepackage` task is executed.
All the above tweaks are usually used to avoid situation where
already created boot jar is repackaged again. Repackaging
already created boot jar is repackaged again. Repackaging
an existing boot jar will not break anything but you may
@ -58,27 +58,15 @@ public class SpringApplicationContextLoader extends AbstractContextLoader {
@@ -58,27 +58,15 @@ public class SpringApplicationContextLoader extends AbstractContextLoader {
@ -86,9 +74,36 @@ public class SpringApplicationContextLoader extends AbstractContextLoader {
@@ -86,9 +74,36 @@ public class SpringApplicationContextLoader extends AbstractContextLoader {