Polish

See gh-19593

Author: bclozel

spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc

@@ -893,6 +893,10 @@ In case your application needs to rely on a specific subset of health checks for
 	management.endpoint.health.group.readiness.include=readinessProbe,customCheck
 ----
 
+WARNING: In general, "Liveness" and "Readiness" probes should avoid being based on external checks, such as <<production-ready-features.adoc#production-ready-health, external Health checks>>.
+If an external system fails (e.g. a database, a Web API, an external cache), Kubernetes would react by restarting application instances or spinning up many new instances.
+You should carefully consider external checks and how the platform should handle such failures.
+
 WARNING: If your Actuator endpoints are deployed on a separate management context, be aware that endpoints are then not using the same web infrastructure (port, connection pools, framework components) as the main application.
 In this case, a Probe check could be successful even if the main application does not work properly (for example, it cannot accept new connections).
 

spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc

@@ -6039,7 +6039,7 @@ The "Readiness" state of an application tells whether the application is ready t
 A failing "Readiness" state tells Kubernetes that it should not route traffic to the application for now.
 This typically happens during startup, while `CommandLineRunner` and `ApplicationRunner` components are being processed, or at any time if the application decides that it's too busy for additional traffic.
 
-An application is considered live as soon as the `ApplicationReadyEvent` has been published, see <<boot-features-application-events-and-listeners, Spring Boot application lifecycle and related Application Events>>.
+An application is considered ready as soon as the `ApplicationReadyEvent` has been published, see <<boot-features-application-events-and-listeners, Spring Boot application lifecycle and related Application Events>>.
 
 TIP: Tasks expected to run during startup should be executed by `CommandLineRunner` and `ApplicationRunner` components instead of using Spring component lifecycle callbacks such as `@PostConstruct`.
 

spring-boot-project/spring-boot/src/main/java/org/springframework/boot/kubernetes/ApplicationStateProvider.java

@@ -16,9 +16,6 @@
 
 package org.springframework.boot.kubernetes;
 
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-
 import org.springframework.context.ApplicationEvent;
 import org.springframework.context.ApplicationListener;
 
@@ -35,8 +32,6 @@
  */
 public class ApplicationStateProvider implements ApplicationListener<ApplicationEvent> {
 
-	private static final Log logger = LogFactory.getLog(ApplicationStateProvider.class);
-
 	private LivenessState livenessState;
 
 	private ReadinessState readinessState;
@@ -63,12 +58,10 @@ public void onApplicationEvent(ApplicationEvent event) {
 		if (event instanceof LivenessStateChangedEvent) {
 			LivenessStateChangedEvent livenessEvent = (LivenessStateChangedEvent) event;
 			this.livenessState = livenessEvent.getLivenessState();
-			logger.info("Application State is now " + this.livenessState.toString());
 		}
 		else if (event instanceof ReadinessStateChangedEvent) {
 			ReadinessStateChangedEvent readinessEvent = (ReadinessStateChangedEvent) event;
 			this.readinessState = readinessEvent.getReadinessState();
-			logger.info("Application State is now " + this.readinessState.toString());
 		}
 	}