There are two configuration files in Spring Boot
- bootstrap (.yml or .properties)
- application (.yml or .properties)
1. The SpringBoot bootstrap configuration file does not take effect
Using SpringBoot alone, I found that the files in it cannot take effect, and changing them to yaml format is useless.
Finally, the investigation found that it was because SpringBoot itself does not support it and needed to be combined with Spring Cloud components - only with Spring Cloud Context dependencies can take effect.
That is, it is introduced in the pom:
<!--Need to introduce thisjarOnly by makingbootstrapConfiguration file takes effect--> <dependency> <groupId></groupId> <artifactId>spring-cloud-context</artifactId> </dependency>
2. The difference between bootstrap/ application
There are two contexts in Spring Boot, one is bootstrap, and the other is application. bootstrap is the parent context of the application, which means that bootstrap loading takes precedence over application.
bootstrap is mainly used to load configuration information from additional resources, and can also decrypt properties in local external configuration files.
These two contexts share an environment, which is the source of external properties of any Spring application. Properties in bootstrap will be loaded first, and they cannot be overwritten by the same local configuration by default.
Therefore, compared with the application configuration file, the bootstrap configuration file has the following characteristics.
- bootstrap is loaded by the parent ApplicationContext and is loaded first than application
- Properties in boostrap cannot be overwritten
3. Application scenarios of bootstrap/ application
The application configuration file is easy to understand and is mainly used for the automated configuration of Spring Boot projects.
The bootstrap configuration file has the following application scenarios.
- When using Spring Cloud Config to configure the center, you need to add configuration properties connected to the configuration center in the bootstrap configuration file to load configuration information of the external configuration center;
- Some fixed properties that cannot be overwritten
- Some encrypted/decrypted scenarios;
Technically, it is loaded by a parent Spring ApplicationContext. This parent's Spring ApplicationContext is loaded first, before the loading of the ApplicationContext.
Why do I need to put the config server information in?
When using Spring Cloud, the configuration information is generally loaded from the config server. In order to obtain configuration information (such as passwords, etc.), you need some early boot configuration. Therefore, put the config server information in , to load the configuration information that is really needed during this period.
4. Advanced usage scenarios
4.1 Start the context
Spring Cloud creates aBootstrap Context, as a Spring applicationApplication Contextparent context.
When initialization,Bootstrap ContextResponsible for loading configuration properties from external sources and resolving configurations. These two contexts share one obtained from the outsideEnvironment。
BootstrapAttributes have high priority and by default they are not overwritten by local configuration.
Bootstrap contextandApplication ContextThere are different agreements, so a new one has been addedFile, not using(or)。
ensureBootstrap ContextandApplication ContextSeparation of configuration.
Here is an example:
spring:
application:
name: foo
cloud:
config:
uri: ${SPRING_CONFIG_URI:http://localhost:8888}Recommended in or Configuration inside. You can set it=falseTo disablebootstrap。
4.2 Application context hierarchy
If you passSpringApplicationorSpringApplicationBuilderCreate aApplication Context, then it will be applied for springApplication ContextCreate parent contextBootstrap Context。
There is a feature in Spring, the child context will inherit the parent classproperty sources and profiles,somain application contextCompared to not using Spring Cloud Config, additional additionalproperty sources。
Extraproperty sourceshave:
- "bootstrap" : If you scan to PropertySourceLocator in the Bootstrap Context and have properties, it will be added to the CompositePropertySource. Spirng Cloud Config is used to add properties in this way. For details, see the source code ConfigServicePropertySourceLocator`. There is also a custom example below.
- "applicationConfig: [classpath:]", (if there is =production, for example applicationConfig: [classpath:/]#production): If you use to configure Bootstrap Context, it is lower than priority. It will be added to the subcontext as part of the Spring Boot application. The following is introduced.
Due to the priority rules, Bootstrap Context does not contain data that has never been done, but it can be used as the default setting.
You can easilyExtend any context hierarchy you create, you can use the interface it provides, or use the methods included in SpringApplicationBuilder (parent(), child(), sibling()).
Bootstrap Context will be the highest-level parent class. Each Context that is extended has its own bootstrap property source (possibly empty).
Each Context that is extended is different. In principle, the parent-son context at the same level also has different names, so there will be different Config Server configurations.
The attributes of the child context will override the attributes of the parent context with the same name.
- Note that SpringApplicationBuilder allows sharing Environment to all levels, but is not the default one.
- Therefore, the sibling context does not necessarily have the same profiles or property sources when it does not share something with the parent class.
4.3 Modify bootstrap attribute configuration
Source code location BootstrapApplicationListener.
String configName = ("${:bootstrap}");
String configLocation = ("${:}");
Map<String, Object> bootstrapMap = new HashMap<>();("",configName);
if((configLocation)){
("", configLocation);
}is by (default: "bootstrap") or (default empty).
These properties behave similarly to .*, and use its Environment to configure the boot ApplicationContext.
If there is an activated profile (or Api build from or Environment), for example, the profile is configured as development.
4.3.1 Overwrite remote properties
property sources are added to the application by bootstrap context usually through remote methods such as "Config Server".
By default, local configuration files cannot overwrite remote configuration, but can be overwritten by starting command line parameters.
If you need to overwrite the remote file, you need to be in the remote configuration file
4.3.2 Setting up authorization
=true (This configuration cannot be set locally).
Once this permission is set, you can configure a more granular configuration to configure the override method.
for example:
- =true Override any local attributes
- =false Only system properties and environment variables
See PropertySourceBootstrapProperties for the source file.
4.4 Custom startup configuration
bootstrap context is a configuration established by the comma-separated Spring @Configuration class under the entries in the /META-INF/ file.
Any automatic injection bean required by the main application context can be obtained in this way here.
This is also how ApplicationContextInitializer creates @Bean.
The initialization sequence can be changed through @Order, the default is "last".
# spring-cloud-context-1.1. # # AutoConfiguration =\ ,\ ,\ ,\ # Application Listeners =\ ,\ # Bootstrap components =\ ,\ ,\ ,\
Adding the custom BootstrapConfiguration class without error @ComponentScanned to your main application context, they may not be needed.
Use an additional package to not be overwritten by @ComponentScan or @SpringBootApplication annotations.
bootstrap context All beans initialized by the configured class will be added to its context before SpringApplicatin is started.
4.5 Custom boot configuration source: Bootstrap Property Sources
Defaultproperty sourceAdding additional configuration is through the Config Server, you can also customize the additionproperty sourceBy implementingPropertySourceLocatorAdd interface.
You can use it to add configuration properties from different services, databases, or others.
Here is a custom example:
@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {
@Override
public PropertySource<?> locate(Environment environment) {
return new MapPropertySource("customProperty",
Collections.<String, Object>singletonMap("", "worked as intended"));
}
}Environment is created by ApplicationContext and property sources are passed in (different profiles may have different properties), so you can find some special properties from Environment.
For example, it is the default Config Server property source.
If you create a jar package, add a META-INF/ file:
=
Then, the "customProperty" PropertySource will be included in the application.
Summarize
The above is personal experience. I hope you can give you a reference and I hope you can support me more.