Spring Cloud Serial Bootstrap context of the first article

1. Spring Cloud context:application Context Services (Application context Service) 1.1 The Bootstrap application context (boot context)

A spring cloud app creates a "bootstrap" context, which is the parent context of the main application. It is responsible for loading the configuration properties of external resources and interpreting the properties in the local external configuration file.

There are two contexts, one is the main context of spring boot and the other is the bootstrap context of Spring cloud, which share the same environment in the two context. This means they share the external configuration properties of the spring project.

By default, the Bootstrap property (not bootstrap.properties but those loaded in the bootstrap phase) is added in a high-priority manner, so it cannot be overwritten by a local configuration.

Bootstrap context and main context use different methods to locate the external configuration, you can use BOOTSTRAP.YML instead of APPLICATION.YML to add a configuration to the bootstrap context. This allows you to distinguish between bootstrap context and main context.

You can disable the bootstrap program by setting Spring.cloud.bootstrap.enabled=false in the System properties.

1.2 Application Context hierarchies (application context level)

If you build a application context through springapplication or springapplicationbuilder, then bootstrap context will act as its parent The context is added.

One feature of spring is that child context inherits property resources and configuration files from its parent context, so the main application context has some additional property resources:

"Bootstrap": if Propertysourcelocators is found in bootstrap context and contains non-empty attributes, then a compositepropertysource will appear with a high priority.

"Applicationconfig": If you have a bootstrap.yml, and you set the properties of the configuration bootstrap context, they will be added to the child context. However, they have a lower priority than application.yml or other configurations.

Because of the collation of resource properties, the "bootstrap" entry has a high priority. Note This does not include data in bootstrap.yml (with a lower priority, which can be used to set default properties).

1.3 Changing the location of Bootstrap Properties

BOOTSTRAP.YML can be specified by setting spring.cloud.bootstrap.name or Spring.cloud.bootstrap.location in the system properties.

If there is an active profile (via Spring.profiles.active or Environment API settings), then the properties in these files will be loaded.

1.4 Overriding the values of the remote properties

Property resources that are added to your app through bootstrap context may often be "remote", such as properties read from spring Cloud Config server. By default, they cannot be overwritten locally.

If you want your app to override those remote configurations through System properties or local configuration, you can set the Remote property resource Spring.cloud.config.allowoverride=true (the local setting is not valid).

Once the above flag is set, the following two remote properties can be used to control the relationship of the remote and System properties to the local configuration:

Spring.cloud.config.overridenone=true: Remote properties can be overridden by any local property resource

Spring.cloud.config.overridesystemproperties=false: Only System Properties, command-line arguments, and environment variables (not including configuration files) can override remote settings.

1.5 Customizing the Bootstrap configuration (custom Bootstrap configurations)

Bootstrap context can be set to do whatever you want to do, as long as the/meta-inf/ You can configure the value of Org.springframework.cloud.bootstrap.BootstrapConfiguration in the Spring.factories file.

Its value is the fully qualified name of the @configuration class, separated by commas. So any bean you want to inject in the main application context can be configured here. If you want to control the boot order, add @order annotations on the class (the default order is final).

Note: Do not bootstrap configuration is overwritten by the main context load, that is, the configuration class that cannot be @componentscan and @springbootapplication annotations.

The bootstrap program finally injects the initializer into the main springapplication instance. First, the bootstrap context is created through the classes configured in Spring.factories, and then all applicationcontextinitializer beans will be added to the main Springapplication, before it starts.

1.6 Customizing the Bootstrap property Sources (custom Bootstrap attribute Resource)

The default property resource for external configuration that is added through the bootstrap program is Spring Cloud Config Server. However, additional resources can be added by adding propertysourcelocator-type beans to bootstrap context (via Spring.factories).

Give me A:

1 @Configuration2  Public classCustompropertysourcelocatorImplementsPropertysourcelocator {3 4 @Override5      PublicPropertysource<?>Locate (Environment environment) {6         return NewMappropertysource ("CustomProperty",7Collections.<string, Object>singletonmap ("Property.from.sample.custom.source", "worked as intended"));8     }9 Ten}

And then META-INF/spring.factories add it in the file

1 org.springframework.cloud.bootstrap.bootstrapconfiguration=sample.custom.custompropertysourcelocator

1.7 Refresh scope (refresh domain)

When the configuration changes, the bean that is marked as @refreshscope gets some special treatment. This feature will solve some of the beans problems of injecting configuration only during initialization.

For example, when the database URL changes, the data source already has some database connections open, and you may want those connections that are already open to be able to complete their work, but when new requests come in to get the connection, they are returned to their new URL connection.

Sometimes it may be mandatory to add @refreshscope annotations on some beans that can only be initialized once. If a bean is "immutable", you will have to add @refreshscope annotations to it or specify class name on the Spring.cloud.refresh.extra-refreshable key.

The beans in the refresh scope are deferred proxies, initialized only when they are used, and the scope is like a cache of initialized values. In order for the bean to reinitialize the next time it is used, its cache entry must be invalidated.

Refreshscope is a bean, and there is a public method Refreshall (), which is used to clean up all the beans in the scope by clearing the target cache.

Endpoint/refresh provides this functionality externally (via HTTP or jmx). You can use the Refresh (String) method if you want to flush the bean through the name of the bean.

To expose the/refresh endpoint, you need to write the following configuration in the configuration file:

1 Management: 2   Endpoints:3    Web:4      exposure:5         Include:refresh

Note: @RefreshScope work on @configuration classes, but there may be some special behavior. For example, it does not mean that all beans defined in the @configuration class are in @refreshscope. So anything that relies on those beans can't be refreshed.

Update.

1.8 Endpoints (Endpoint)

If your app is a spring Boot actuator then there are some additional administrative endpoints:

Sending a POST request to/actuator/env can update environment, rebind, @ConfigurationProperties and log levels;

/actuator/refresh Reload Bootstrap context and refresh the bean in @refreshscope;

/actuator/restart Restart ApplicationContext (this feature is turned off by default);

/actuator/pause and/actuator/resume are the life cycle methods that are raised in ApplicationContext stop () and start ()

Note: If the/actuator/restart endpoint is disabled then/actuator/pause and/actuator/resume will also be banned.