Polish document (#1510)

Signed-off-by: Tran Ngoc Nhan <ngocnhan.tran1996@gmail.com>

docs/modules/ROOT/pages/spring-cloud-commons/application-context-services.adoc

@@ -167,7 +167,7 @@ Generally, we would not recommend that approach for detecting changes (although
 If you have a scaled-out client application, it is better to broadcast the `EnvironmentChangeEvent` to all the instances instead of having them polling for changes (for example, by using the https://github.com/spring-cloud/spring-cloud-bus[Spring Cloud Bus]).
 
 The `EnvironmentChangeEvent` covers a large class of refresh use cases, as long as you can actually make a change to the `Environment` and publish the event.
-Note that those APIs are public and part of core Spring).
+Note that those APIs are public and part of core Spring.
 You can verify that the changes are bound to `@ConfigurationProperties` beans by visiting the `/configprops` endpoint (a standard Spring Boot Actuator feature).
 For instance, a `DataSource` can have its `maxPoolSize` changed at runtime (the default `DataSource` created by Spring Boot is a `@ConfigurationProperties` bean) and grow capacity dynamically.
 Re-binding `@ConfigurationProperties` does not cover another large class of use cases, where you need more control over the refresh and where you need a change to be atomic over the whole `ApplicationContext`.

docs/modules/ROOT/pages/spring-cloud-commons/common-abstractions.adoc

@@ -110,6 +110,7 @@ are using.
 
 By default, the `ServiceRegistry` implementation auto-registers the running service.
 To disable that behavior, you can set:
+
 * `@EnableDiscoveryClient(autoRegister=false)` to permanently disable auto-registration.
 * `spring.cloud.service-registry.auto-registration.enabled=false` to disable the behavior through configuration.