mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-07-15 01:07:30 +08:00
Polish documentation title case
This commit is contained in:
parent
65bdcdb2a5
commit
c416c17fe8
@ -1034,7 +1034,7 @@ This would make `liveness` available at `/livez` and `readiness` at `readyz` on
|
||||
|
||||
|
||||
[[actuator.endpoints.kubernetes-probes.external-state]]
|
||||
==== Checking External State with Kubernetes Probes
|
||||
==== Checking External State With Kubernetes Probes
|
||||
Actuator configures the "`liveness`" and "`readiness`" probes as Health Groups.
|
||||
This means that all the <<actuator#actuator.endpoints.health.groups, health groups features>> are available for them.
|
||||
You can, for example, configure additional Health Indicators:
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[actuator.monitoring]]
|
||||
== Monitoring and Management over HTTP
|
||||
== Monitoring and Management Over HTTP
|
||||
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`.
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[cli.groovy-beans-dsl]]
|
||||
== Developing Applications with the Groovy Beans DSL
|
||||
== Developing Applications With the Groovy Beans DSL
|
||||
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:
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[cli.maven-setting]]
|
||||
== Configuring the CLI with settings.xml
|
||||
== Configuring the CLI With settings.xml
|
||||
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:
|
||||
|
@ -50,7 +50,7 @@ The `version` command provides a quick way to check which version of Spring Boot
|
||||
|
||||
|
||||
[[cli.using-the-cli.run]]
|
||||
=== Running Applications with the CLI
|
||||
=== Running Applications With the CLI
|
||||
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.
|
||||
|
||||
@ -197,7 +197,7 @@ However, to ensure consistent ordering of the dependency management, you can use
|
||||
|
||||
|
||||
[[cli.using-the-cli.multiple-source-files]]
|
||||
=== Applications with Multiple Source Files
|
||||
=== Applications With 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:
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[container-images.efficient-images]]
|
||||
== Efficient container images
|
||||
== Efficient Container Images
|
||||
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.
|
||||
@ -9,7 +9,7 @@ If you put jar files in the layer before your application classes, Docker often
|
||||
|
||||
|
||||
[[container-images.efficient-images.unpacking]]
|
||||
=== Unpacking the fat jar
|
||||
=== Unpacking the Executable JAR
|
||||
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.
|
||||
|
@ -275,7 +275,7 @@ Spring Boot provides a dedicated "`Starter`", `spring-boot-starter-data-elastics
|
||||
|
||||
|
||||
[[data.nosql.elasticsearch.connecting-using-rest]]
|
||||
==== Connecting to Elasticsearch using REST clients
|
||||
==== Connecting to Elasticsearch Using REST clients
|
||||
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`.
|
||||
@ -293,7 +293,7 @@ You can use `spring.elasticsearch.*` properties to further tune how the clients
|
||||
----
|
||||
|
||||
[[data.nosql.elasticsearch.connecting-using-rest.restclient]]
|
||||
===== Connecting to Elasticsearch using RestHighLevelClient
|
||||
===== Connecting to Elasticsearch Using RestHighLevelClient
|
||||
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.
|
||||
@ -316,7 +316,7 @@ You can further tune how `Sniffer` is configured, as shown in the following exam
|
||||
|
||||
|
||||
[[data.nosql.elasticsearch.connecting-using-rest.webclient]]
|
||||
===== Connecting to Elasticsearch using ReactiveElasticsearchClient
|
||||
===== Connecting to Elasticsearch Using ReactiveElasticsearchClient
|
||||
{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.
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[documentation.using]]
|
||||
== Developing with Spring Boot
|
||||
== Developing With Spring Boot
|
||||
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>>
|
||||
|
@ -26,7 +26,7 @@ We do not need to unpack the archive, and we do not need to read all entry data
|
||||
|
||||
|
||||
[[appendix.executable-jar.jarfile-class.compatibility]]
|
||||
=== Compatibility with the Standard Java "`JarFile`"
|
||||
=== Compatibility With the Standard Java "`JarFile`"
|
||||
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`.
|
||||
|
@ -101,7 +101,7 @@ This means that the JSON cannot override properties from lower order property so
|
||||
|
||||
|
||||
[[features.external-config.files]]
|
||||
=== External Application Properties [[features.external-config.files]]
|
||||
=== External Application Properties
|
||||
Spring Boot will automatically find and load `application.properties` and `application.yaml` files from the following locations when your application starts:
|
||||
|
||||
. From the classpath
|
||||
@ -474,7 +474,7 @@ See the _<<howto#howto.properties-and-configuration.short-command-line-arguments
|
||||
|
||||
|
||||
[[features.external-config.files.multi-document]]
|
||||
==== Working with Multi-Document Files
|
||||
==== Working With Multi-Document Files
|
||||
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.
|
||||
@ -567,7 +567,7 @@ If you need a secure way to store credentials and passwords, the https://cloud.s
|
||||
|
||||
|
||||
[[features.external-config.yaml]]
|
||||
=== Working with YAML
|
||||
=== Working With 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.
|
||||
|
||||
@ -680,7 +680,7 @@ TIP: See also the <<features#features.external-config.typesafe-configuration-pro
|
||||
|
||||
|
||||
[[features.external-config.typesafe-configuration-properties.java-bean-binding]]
|
||||
==== JavaBean properties binding
|
||||
==== JavaBean Properties Binding
|
||||
It is possible to bind a bean declaring standard JavaBean properties as shown in the following example:
|
||||
|
||||
[source,java,indent=0,subs="verbatim"]
|
||||
@ -721,7 +721,7 @@ Finally, only standard Java Bean properties are considered and binding on static
|
||||
|
||||
|
||||
[[features.external-config.typesafe-configuration-properties.constructor-binding]]
|
||||
==== Constructor binding
|
||||
==== 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"]
|
||||
@ -760,7 +760,7 @@ For consistency with properties of other types, if you do declare an `Optional`
|
||||
|
||||
|
||||
[[features.external-config.typesafe-configuration-properties.enabling-annotated-types]]
|
||||
==== Enabling @ConfigurationProperties-annotated types
|
||||
==== Enabling @ConfigurationProperties-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.
|
||||
|
||||
@ -798,7 +798,7 @@ If you still want to inject other beans using the constructor, the configuration
|
||||
|
||||
|
||||
[[features.external-config.typesafe-configuration-properties.using-annotated-types]]
|
||||
==== Using @ConfigurationProperties-annotated types
|
||||
==== Using @ConfigurationProperties-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"]
|
||||
@ -941,7 +941,7 @@ For example, binding `a.b=c` to `Map<String, Object>` will return a Map with the
|
||||
|
||||
|
||||
[[features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables]]
|
||||
===== Binding from Environment Variables
|
||||
===== Binding From 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.
|
||||
@ -1117,7 +1117,7 @@ Doing so gives a transparent upgrade path while supporting a much richer format.
|
||||
|
||||
|
||||
[[features.external-config.typesafe-configuration-properties.conversion.periods]]
|
||||
===== Converting periods
|
||||
===== Converting Periods
|
||||
In addition to durations, Spring Boot can also work with `java.time.Period` type.
|
||||
The following formats can be used in application properties:
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[features.kotlin]]
|
||||
== Kotlin support
|
||||
== Kotlin Support
|
||||
https://kotlinlang.org[Kotlin] is a statically-typed language targeting the JVM (and other platforms) which allows writing concise and elegant code while providing {kotlin-docs}java-interop.html[interoperability] with existing libraries written in Java.
|
||||
|
||||
Spring Boot provides Kotlin support by leveraging the support in other Spring projects such as Spring Framework, Spring Data, and Reactor.
|
||||
|
@ -171,7 +171,7 @@ include::{docs-java}/features/testing/springbootapplications/usingapplicationarg
|
||||
|
||||
|
||||
[[features.testing.spring-boot-applications.with-mock-environment]]
|
||||
==== Testing with a mock environment
|
||||
==== Testing With a Mock Environment
|
||||
By default, `@SpringBootTest` does not start the server but instead sets up a mock environment for testing web endpoints.
|
||||
|
||||
With Spring MVC, we can query our web endpoints using {spring-framework-docs}/testing.html#spring-mvc-test-framework[`MockMvc`] or `WebTestClient`, as shown in the following example:
|
||||
@ -203,7 +203,7 @@ If you need to test these lower-level concerns, you can start a fully running se
|
||||
|
||||
|
||||
[[features.testing.spring-boot-applications.with-running-server]]
|
||||
==== Testing with a running server
|
||||
==== Testing With a Running Server
|
||||
If you need to start a full running server, we recommend that you use random ports.
|
||||
If you use `@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)`, an available port is picked at random each time your test runs.
|
||||
|
||||
@ -710,7 +710,7 @@ It can also be used to configure the host, scheme, and port that appears in any
|
||||
|
||||
|
||||
[[features.testing.spring-boot-applications.autoconfigured-spring-restdocs.with-mock-mvc]]
|
||||
===== Auto-configured Spring REST Docs Tests with Mock MVC
|
||||
===== Auto-configured Spring REST Docs Tests With Mock MVC
|
||||
`@AutoConfigureRestDocs` customizes the `MockMvc` bean to use Spring REST Docs when testing servlet-based web applications.
|
||||
You can inject it by using `@Autowired` and use it in your tests as you normally would when using Mock MVC and Spring REST Docs, as shown in the following example:
|
||||
|
||||
@ -738,7 +738,7 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredsprin
|
||||
|
||||
|
||||
[[features.testing.spring-boot-applications.autoconfigured-spring-restdocs.with-web-test-client]]
|
||||
===== Auto-configured Spring REST Docs Tests with WebTestClient
|
||||
===== Auto-configured Spring REST Docs Tests With WebTestClient
|
||||
`@AutoConfigureRestDocs` can also be used with `WebTestClient` when testing reactive web applications.
|
||||
You can inject it by using `@Autowired` and use it in your tests as you normally would when using `@WebFluxTest` and Spring REST Docs, as shown in the following example:
|
||||
|
||||
@ -765,7 +765,7 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredsprin
|
||||
|
||||
|
||||
[[features.testing.spring-boot-applications.autoconfigured-spring-restdocs.with-rest-assured]]
|
||||
===== Auto-configured Spring REST Docs Tests with REST Assured
|
||||
===== Auto-configured Spring REST Docs Tests With REST Assured
|
||||
`@AutoConfigureRestDocs` makes a `RequestSpecification` bean, preconfigured to use Spring REST Docs, available to your tests.
|
||||
You can inject it by using `@Autowired` and use it in your tests as you normally would when using REST Assured and Spring REST Docs, as shown in the following example:
|
||||
|
||||
|
@ -30,7 +30,7 @@ See {spring-boot-autoconfigure-module-code}/batch/BatchAutoConfiguration.java[Ba
|
||||
|
||||
|
||||
[[howto.batch.running-from-the-command-line]]
|
||||
=== Running from the Command Line
|
||||
=== Running From the Command Line
|
||||
Spring Boot converts any command line argument starting with `--` to a property to add to the `Environment`, see <<features#features.external-config.command-line-args,accessing command line properties>>.
|
||||
This should not be used to pass arguments to batch jobs.
|
||||
To specify batch arguments on the command line, use the regular format (that is without `--`), as shown in the following example:
|
||||
|
@ -257,7 +257,7 @@ See {spring-boot-maven-plugin-docs}#run-example-debug[this example] for more det
|
||||
|
||||
|
||||
[[howto.build.build-an-executable-archive-with-ant-without-using-spring-boot-antlib]]
|
||||
=== Build an Executable Archive from Ant without Using spring-boot-antlib
|
||||
=== Build an Executable Archive From Ant without Using spring-boot-antlib
|
||||
To build with Ant, you need to grab dependencies, compile, and then create a jar or war archive.
|
||||
To make it executable, you can either use the `spring-boot-antlib` module or you can follow these instructions:
|
||||
|
||||
|
@ -219,7 +219,7 @@ The details of the `h2` support depend on the chosen web server and the applicat
|
||||
|
||||
|
||||
[[howto.webserver.configure-http2.tomcat]]
|
||||
==== HTTP/2 with Tomcat
|
||||
==== HTTP/2 With Tomcat
|
||||
Spring Boot ships by default with Tomcat 9.0.x which supports `h2c` out of the box and `h2` out of the box when using JDK 9 or later.
|
||||
Alternatively, `h2` can be used on JDK 8 if the `libtcnative` library and its dependencies are installed on the host operating system.
|
||||
|
||||
@ -239,7 +239,7 @@ This error is not fatal, and the application still starts with HTTP/1.1 SSL supp
|
||||
|
||||
|
||||
[[howto.webserver.configure-http2.jetty]]
|
||||
==== HTTP/2 with Jetty
|
||||
==== HTTP/2 With Jetty
|
||||
For HTTP/2 support, Jetty requires the additional `org.eclipse.jetty.http2:http2-server` dependency.
|
||||
To use `h2c` no other dependencies are required.
|
||||
To use `h2`, you also need to choose one of the following dependencies, depending on your deployment:
|
||||
@ -251,7 +251,7 @@ To use `h2`, you also need to choose one of the following dependencies, dependin
|
||||
|
||||
|
||||
[[howto.webserver.configure-http2.netty]]
|
||||
==== HTTP/2 with Reactor Netty
|
||||
==== HTTP/2 With Reactor Netty
|
||||
The `spring-boot-webflux-starter` is using by default Reactor Netty as a server.
|
||||
Reactor Netty supports `h2c` using JDK 8 or later with no additional dependencies.
|
||||
Reactor Netty supports `h2` using the JDK support with JDK 9 or later.
|
||||
@ -264,7 +264,7 @@ Developers can choose to import only the required dependencies using a classifie
|
||||
|
||||
|
||||
[[howto.webserver.configure-http2.undertow]]
|
||||
==== HTTP/2 with Undertow
|
||||
==== HTTP/2 With Undertow
|
||||
As of Undertow 1.4.0+, both `h2` and `h2c` are supported on JDK 8 without any additional dependencies.
|
||||
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[io.jta]]
|
||||
== Distributed Transactions with JTA
|
||||
== Distributed Transactions With JTA
|
||||
Spring Boot supports distributed JTA transactions across multiple XA resources by using an https://www.atomikos.com/[Atomikos] embedded transaction manager.
|
||||
JTA transactions are also supported when deploying to a suitable Java EE Application Server.
|
||||
|
||||
|
@ -7,7 +7,7 @@ Spring Boot offers several conveniences for working with AMQP through RabbitMQ,
|
||||
|
||||
|
||||
[[messaging.amqp.rabbitmq]]
|
||||
=== RabbitMQ support
|
||||
=== RabbitMQ Support
|
||||
https://www.rabbitmq.com/[RabbitMQ] is a lightweight, reliable, scalable, and portable message broker based on the AMQP protocol.
|
||||
Spring uses `RabbitMQ` to communicate through the AMQP protocol.
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
[[upgrading.from-1x]]
|
||||
== Upgrading from 1.x
|
||||
== Upgrading From 1.x
|
||||
|
||||
If you are upgrading from the `1.x` release of Spring Boot, check the {github-wiki}/Spring-Boot-2.0-Migration-Guide["`migration guide`" on the project wiki] that provides detailed upgrade instructions.
|
||||
Check also the {github-wiki}["`release notes`"] for a list of "`new and noteworthy`" features for each release.
|
@ -1,5 +1,5 @@
|
||||
[[upgrading.to-feature]]
|
||||
== Upgrading to a new feature release
|
||||
== Upgrading to a New Feature Release
|
||||
|
||||
When upgrading to a new feature release, some properties may have been renamed or removed.
|
||||
Spring Boot provides a way to analyze your application's environment and print diagnostics at startup, but also temporarily migrate properties at runtime for you.
|
||||
|
@ -130,7 +130,7 @@ These work by rewriting classes as they are loaded to make them more amenable to
|
||||
|
||||
|
||||
[[using.devtools.restart.logging-condition-delta]]
|
||||
==== Logging changes in condition evaluation
|
||||
==== Logging Changes in Condition Evaluation
|
||||
By default, each time your application restarts, a report showing the condition evaluation delta is logged.
|
||||
The report shows the changes to your application's auto-configuration as you make changes such as adding or removing beans and setting configuration properties.
|
||||
|
||||
|
@ -10,7 +10,7 @@ If you choose to package your application as a war file, see your server and IDE
|
||||
|
||||
|
||||
[[using.running-your-application.from-an-ide]]
|
||||
=== Running from an IDE
|
||||
=== Running From an IDE
|
||||
You can run a Spring Boot application from your IDE as a Java application.
|
||||
However, you first need to import your project.
|
||||
Import steps vary depending on your IDE and build system.
|
||||
|
@ -433,7 +433,7 @@ The `ErrorController` then picks up any unhandled exceptions.
|
||||
|
||||
|
||||
[[web.servlet.spring-mvc.error-handling.error-pages-without-spring-mvc]]
|
||||
===== Mapping Error Pages outside of Spring MVC
|
||||
===== Mapping Error Pages Outside of Spring MVC
|
||||
For applications that do not use Spring MVC, you can use the `ErrorPageRegistrar` interface to directly register `ErrorPages`.
|
||||
This abstraction works directly with the underlying embedded servlet container and works even if you do not have a Spring MVC `DispatcherServlet`.
|
||||
|
||||
@ -454,7 +454,7 @@ Note that the default `FilterRegistrationBean` does not include the `ERROR` disp
|
||||
|
||||
|
||||
[[web.servlet.spring-mvc.error-handling.in-a-war-deployment]]
|
||||
===== Error handling in a war deployment
|
||||
===== Error Handling in a WAR Deployment
|
||||
When deployed to a servlet container, Spring Boot uses its error page filter to forward a request with an error status to the appropriate error page.
|
||||
This is necessary as the servlet specification does not provide an API for registering error pages.
|
||||
Depending on the container that you are deploying your war file to and the technologies that your application uses, some additional configuration may be required.
|
||||
@ -534,7 +534,7 @@ By default, the embedded server listens for HTTP requests on port `8080`.
|
||||
|
||||
|
||||
[[web.servlet.embedded-container.servlets-filters-listeners]]
|
||||
==== Servlets, Filters, and listeners
|
||||
==== Servlets, Filters, and Listeners
|
||||
When using an embedded servlet container, you can register servlets, filters, and all the listeners (such as `HttpSessionListener`) from the servlet spec, either by using Spring beans or by scanning for servlet components.
|
||||
|
||||
|
||||
|
@ -153,7 +153,7 @@ For production environments, consider using a `JdbcOAuth2AuthorizedClientService
|
||||
|
||||
|
||||
[[web.security.oauth2.client.common-providers]]
|
||||
===== OAuth2 client registration for common providers
|
||||
===== OAuth2 Client Registration for Common Providers
|
||||
For common OAuth2 and OpenID providers, including Google, Github, Facebook, and Okta, we provide a set of provider defaults (`google`, `github`, `facebook`, and `okta`, respectively).
|
||||
|
||||
If you do not need to customize these providers, you can set the `provider` attribute to the one for which you need to infer defaults.
|
||||
|
Loading…
Reference in New Issue
Block a user