[[propertysource-reload]]
= `PropertySource` Reload

WARNING:  This functionality has been deprecated in the 2020.0 release.  Please see
the xref:spring-cloud-kubernetes-configuration-watcher.adoc#spring-cloud-kubernetes-configuration-watcher[Spring Cloud Kubernetes Configuration Watcher]
controller for an alternative way to achieve the same functionality.

Some applications may need to detect changes on external property sources and update their internal status to reflect the new configuration.
The reload feature of Spring Cloud Kubernetes is able to trigger an application reload when a related `ConfigMap` or
`Secret` changes.

By default, this feature is disabled. You can enable it by using the `spring.cloud.kubernetes.reload.enabled=true` configuration property (for example, in the `application.properties` file).
Please notice that this will enable monitoring of configmaps only (i.e.: `spring.cloud.kubernetes.reload.monitoring-config-maps` will be set to `true`).
If you want to enable monitoring of secrets, this must be done explicitly via : `spring.cloud.kubernetes.reload.monitoring-secrets=true`.

The following levels of reload are supported (by setting the `spring.cloud.kubernetes.reload.strategy` property):

* `refresh` (default): Only configuration beans annotated with `@ConfigurationProperties` or `@RefreshScope` are reloaded.
This reload level leverages the refresh feature of Spring Cloud Context.

* `restart_context`: the whole Spring `ApplicationContext` is gracefully restarted. Beans are recreated with the new configuration.
In order for the restart context functionality to work properly you must enable and expose the restart actuator endpoint
[source,yaml]
====
----
management:
  endpoint:
    restart:
      enabled: true
  endpoints:
    web:
      exposure:
        include: restart
----
====

* `shutdown`: the Spring `ApplicationContext` is shut down to activate a restart of the container.
 When you use this level, make sure that the lifecycle of all non-daemon threads is bound to the `ApplicationContext`
and that a replication controller or replica set is configured to restart the pod.

Assuming that the reload feature is enabled with default settings (`refresh` mode), the following bean is refreshed when the config map changes:

[java, source]
----
@Configuration
@ConfigurationProperties(prefix = "bean")
public class MyConfig {

    private String message = "a message that can be changed live";

    // getter and setters

}
----

To see that changes effectively happen, you can create another bean that prints the message periodically, as follows

[source,java]
----
@Component
public class MyBean {

    @Autowired
    private MyConfig config;

    @Scheduled(fixedDelay = 5000)
    public void hello() {
        System.out.println("The message is: " + config.getMessage());
    }
}
----

You can change the message printed by the application by using a `ConfigMap`, as follows:

[source,yaml]
----
apiVersion: v1
kind: ConfigMap
metadata:
  name: reload-example
data:
  application.properties: |-
    bean.message=Hello World!
----

Any change to the property named `bean.message` in the `ConfigMap` associated with the pod is reflected in the
output. More generally speaking, changes associated to properties prefixed with the value defined by the `prefix`
field of the `@ConfigurationProperties` annotation are detected and reflected in the application.
xref:property-source-config/configmap-propertysource.adoc[Associating a `ConfigMap` with a pod] is explained earlier in this chapter.

The reload feature supports two operating modes:

* Event (default): Watches for changes in config maps or secrets by using the Kubernetes API (web socket).
Any event produces a re-check on the configuration and, in case of changes, a reload.
The `view` role on the service account is required in order to listen for config map changes. A higher level role (such as `edit`) is required for secrets
(by default, secrets are not monitored).
* Polling: Periodically re-creates the configuration from config maps and secrets to see if it has changed.
You can configure the polling period by using the `spring.cloud.kubernetes.reload.period` property and defaults to 15 seconds.
It requires the same role as the monitored property source.
This means, for example, that using polling on file-mounted secret sources does not require particular privileges.

