If you are developing a web application, Spring Boot Actuator auto-configures all enabled endpoints to be exposed over HTTP.

The default convention is to use the `id` of the endpoint with a prefix of `/actuator` as the URL path.

For example, `health` is exposed as `/actuator/health`.

Spring Framework 4.0 has native support for a `beans{}` "`DSL`" (borrowed from https://grails.org/[Grails]), and you can embed bean definitions in your Groovy application scripts by using the same format.

This is sometimes a good way to include external features like middleware declarations, as shown in the following example:

The Spring Boot CLI uses Maven Resolver, Maven's dependency resolution engine, to resolve dependencies.

The CLI makes use of the Maven configuration found in `~/.m2/settings.xml` to configure Maven Resolver.

The following configuration settings are honored by the CLI:

[[cli.using-the-cli.run]]

You can compile and run Groovy source code by using the `run` command.

The Spring Boot CLI is completely self-contained, so you do not need any external Groovy installation.

[[cli.using-the-cli.multiple-source-files]]

You can use "`shell globbing`" with all commands that accept file input.

Doing so lets you use multiple files from a single directory, as shown in the following example:

It is easily possible to package a Spring Boot fat jar as a docker image.

However, there are various downsides to copying and running the fat jar as is in the docker image.

There’s always a certain amount of overhead when running a fat jar without unpacking it, and in a containerized environment this can be noticeable.

[[container-images.efficient-images.unpacking]]

If you are running your application from a container, you can use an executable jar, but it is also often an advantage to explode it and run it in a different way.

Certain PaaS implementations may also choose to unpack archives before they run.

For example, Cloud Foundry operates this way.

[[data.nosql.elasticsearch.connecting-using-rest]]

Elasticsearch ships https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/index.html[two different REST clients] that you can use to query a cluster: the "Low Level" client and the "High Level" client.

Spring Boot provides support for the "High Level" client, which ships with `org.elasticsearch.client:elasticsearch-rest-high-level-client`.

Additionally, Spring Boot provides support for a reactive client, based on Spring Framework's `WebClient`, that ships with `org.springframework.data:spring-data-elasticsearch`.

[[data.nosql.elasticsearch.connecting-using-rest.restclient]]

If you have `elasticsearch-rest-high-level-client` on the classpath, Spring Boot will auto-configure and register a `RestHighLevelClient` bean.

In addition to the properties described previously, to fine-tune the `RestHighLevelClient`, you can register an arbitrary number of beans that implement `RestClientBuilderCustomizer` for more advanced customizations.

To take full control over its registration, define a `RestClientBuilder` bean.

[[data.nosql.elasticsearch.connecting-using-rest.webclient]]

{spring-data-elasticsearch}[Spring Data Elasticsearch] ships `ReactiveElasticsearchClient` for querying Elasticsearch instances in a reactive fashion.

It is built on top of WebFlux's `WebClient`, so both `spring-boot-starter-elasticsearch` and `spring-boot-starter-webflux` dependencies are useful to enable this support.

Ready to actually start using Spring Boot? <<using#using, We have you covered>>:

* *Build systems:* <<using#using.build-systems.maven, Maven>> | <<using#using.build-systems.gradle, Gradle>> | <<using#using.build-systems.ant, Ant>> | <<using#using.build-systems.starters, Starters>>

[[appendix.executable-jar.jarfile-class.compatibility]]

Spring Boot Loader strives to remain compatible with existing code and libraries.

`org.springframework.boot.loader.jar.JarFile` extends from `java.util.jar.JarFile` and should work as a drop-in replacement.

The `getURL()` method returns a `URL` that opens a connection compatible with `java.net.JarURLConnection` and can be used with Java's `URLClassLoader`.

[[features.external-config.files]]

Spring Boot will automatically find and load `application.properties` and `application.yaml` files from the following locations when your application starts:

. From the classpath

[[features.external-config.files.multi-document]]

Spring Boot allows you to split a single physical file into multiple logical documents which are each added independently.

Documents are processed in order, from top to bottom.

Later documents can override the properties defined in earlier ones.

[[features.external-config.yaml]]

https://yaml.org[YAML] is a superset of JSON and, as such, is a convenient format for specifying hierarchical configuration data.

The `SpringApplication` class automatically supports YAML as an alternative to properties whenever you have the https://github.com/snakeyaml/snakeyaml[SnakeYAML] library on your classpath.

[[features.external-config.typesafe-configuration-properties.java-bean-binding]]

It is possible to bind a bean declaring standard JavaBean properties as shown in the following example:

[source,java,indent=0,subs="verbatim"]

[[features.external-config.typesafe-configuration-properties.constructor-binding]]

The example in the previous section can be rewritten in an immutable fashion as shown in the following example:

[source,java,indent=0,subs="verbatim"]

[[features.external-config.typesafe-configuration-properties.enabling-annotated-types]]

Spring Boot provides infrastructure to bind `@ConfigurationProperties` types and register them as beans.

You can either enable configuration properties on a class-by-class basis or enable configuration property scanning that works in a similar manner to component scanning.

[[features.external-config.typesafe-configuration-properties.using-annotated-types]]

This style of configuration works particularly well with the `SpringApplication` external YAML configuration, as shown in the following example:

[source,yaml,indent=0,subs="verbatim"]

[[features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables]]

Most operating systems impose strict rules around the names that can be used for environment variables.

For example, Linux shell variables can contain only letters (`a` to `z` or `A` to `Z`), numbers (`0` to `9`) or the underscore character (`_`).

By convention, Unix shell variables will also have their names in UPPERCASE.

[[features.external-config.typesafe-configuration-properties.conversion.periods]]

In addition to durations, Spring Boot can also work with `java.time.Period` type.

The following formats can be used in application properties: