mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-09-03 04:26:12 +08:00
Correct the syntax that's used for smart single and double quotes
Fixes gh-1753
This commit is contained in:
Andy Wilkinson
parent
ae503c62d2
commit
f58b8366e1
@ -10,7 +10,7 @@ application for more details of which features are switched on.
|
||||
|
||||
|
||||
[[auto-configuration-classes-from-autoconfigure-module]]
|
||||
=== From the ``spring-boot-autoconfigure'' module
|
||||
=== From the "`spring-boot-autoconfigure`" module
|
||||
The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
|
||||
|
||||
include::../../../target/generated-resources/auto-configuration-classes-spring-boot-autoconfigure.adoc[]
|
||||
@ -18,7 +18,7 @@ include::../../../target/generated-resources/auto-configuration-classes-spring-b
|
||||
|
||||
|
||||
[[auto-configuration-classes-from-actuator]]
|
||||
=== From the ``spring-boot-actuator'' module
|
||||
=== From the "`spring-boot-actuator`" module
|
||||
The following auto-configuration classes are from the `spring-boot-actuator` module:
|
||||
|
||||
include::../../../target/generated-resources/auto-configuration-classes-spring-boot-actuator.adoc[]
|
||||
|
||||
@ -18,7 +18,7 @@ are themselves contained within a jar). This can be problematic if you are looki
|
||||
to distribute a self-contained application that you can just run from the command line
|
||||
without unpacking.
|
||||
|
||||
To solve this problem, many developers use ``shaded'' jars. A shaded jar simply packages
|
||||
To solve this problem, many developers use "`shaded`" jars. A shaded jar simply packages
|
||||
all classes, from all jars, into a single 'uber jar'. The problem with shaded jars is
|
||||
that it becomes hard to see which libraries you are actually using in your application.
|
||||
It can also be problematic if the the same filename is used (but with different content)
|
||||
@ -91,7 +91,7 @@ a traditional web container should be placed in `WEB-INF/lib-provided`.
|
||||
|
||||
|
||||
[[executable-jar-jarfile]]
|
||||
=== Spring Boot's ``JarFile'' class
|
||||
=== Spring Boot's "`JarFile`" class
|
||||
The core class used to support loading nested jars is
|
||||
`org.springframework.boot.loader.jar.JarFile`. It allows you load jar
|
||||
content from a standard jar file, or from nested child jar data. When first loaded, the
|
||||
@ -121,7 +121,7 @@ need to read all entry data into memory.
|
||||
|
||||
|
||||
[[executable-jar-jarfile-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 `RandomAccessJarFile.getURL()` method will
|
||||
|
||||
@ -7,7 +7,7 @@ Spring Boot provides build tool plugins for Maven and Gradle. The plugins offer
|
||||
variety of features, including the packaging of executable jars. This section provides
|
||||
more details on both plugins, as well as some help should you need to extend an
|
||||
unsupported build system. If you are just getting started, you might want to read
|
||||
``<<using-spring-boot.adoc#using-boot-build-systems>>'' from the
|
||||
"`<<using-spring-boot.adoc#using-boot-build-systems>>`" from the
|
||||
<<using-spring-boot.adoc#using-boot>> section first.
|
||||
--
|
||||
|
||||
@ -17,7 +17,7 @@ unsupported build system. If you are just getting started, you might want to rea
|
||||
== Spring Boot Maven plugin
|
||||
The {spring-boot-maven-plugin-site}/[Spring Boot Maven Plugin] provides Spring Boot
|
||||
support in Maven, allowing you to package executable jar or war archives and run an
|
||||
application ``in-place''. To use it you must be using Maven 3 (or better).
|
||||
application "`in-place`". To use it you must be using Maven 3 (or better).
|
||||
|
||||
NOTE: Refer to the {spring-boot-maven-plugin-site}/[Spring Boot Maven Plugin Site]
|
||||
for complete plugin documentation.
|
||||
@ -129,7 +129,7 @@ To build and run a project artifact, you can type the following:
|
||||
----
|
||||
|
||||
To build a war file that is both executable and deployable into an external container you
|
||||
need to mark the embedded container dependencies as ``provided'', e.g:
|
||||
need to mark the embedded container dependencies as "`provided`", e.g:
|
||||
|
||||
[source,xml,indent=0,subs="verbatim,attributes"]
|
||||
----
|
||||
@ -163,7 +163,7 @@ Advanced configuration options and examples are available in the
|
||||
== Spring Boot Gradle plugin
|
||||
The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, allowing you to
|
||||
package executable jar or war archives, run Spring Boot applications and omit version
|
||||
information from your `build.gradle` file for ``blessed'' dependencies.
|
||||
information from your `build.gradle` file for "`blessed`" dependencies.
|
||||
|
||||
|
||||
|
||||
@ -201,7 +201,7 @@ If you are using a milestone or snapshot release you will also need to add appro
|
||||
[[build-tool-plugins-gradle-dependencies-without-versions]]
|
||||
=== Declaring dependencies without versions
|
||||
The `spring-boot` plugin will register a custom Gradle `ResolutionStrategy` with your
|
||||
build that allows you to omit version numbers when declaring dependencies to ``blessed''
|
||||
build that allows you to omit version numbers when declaring dependencies to "`blessed`"
|
||||
artifacts. To make use of this functionality, simply declare dependencies in the usual way,
|
||||
but leave the version number empty:
|
||||
|
||||
@ -215,7 +215,7 @@ but leave the version number empty:
|
||||
----
|
||||
|
||||
NOTE: The version of the `spring-boot` gradle plugin that you declare determines the
|
||||
actual versions of the ``blessed'' dependencies (this ensures that builds are always
|
||||
actual versions of the "`blessed`" dependencies (this ensures that builds are always
|
||||
repeatable). You should always set the version of the `spring-boot` gradle plugin to the
|
||||
actual Spring Boot version that you wish to use. Details of the versions that are
|
||||
provided can be found in the <<appendix-dependency-versions, appendix>>.
|
||||
@ -237,7 +237,7 @@ example:
|
||||
[[build-tool-plugins-gradle-custom-version-management]]
|
||||
==== Custom version management
|
||||
If is possible to customize the versions used by the `ResolutionStrategy` if you need
|
||||
to deviate from Spring Boot's ``blessed'' dependencies. Alternative version metadata
|
||||
to deviate from Spring Boot's "`blessed`" dependencies. Alternative version metadata
|
||||
is consulted using the `versionManagement` configuration. For example:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes"]
|
||||
@ -263,7 +263,7 @@ to override version numbers if necessary.
|
||||
|
||||
[[build-tool-plugins-gradle-exclude-rules]]
|
||||
=== Default exclude rules
|
||||
Gradle handles ``exclude rules'' in a slightly different way to Maven which can cause
|
||||
Gradle handles "`exclude rules`" in a slightly different way to Maven which can cause
|
||||
unexpected results when using the starter POMs. Specifically, exclusions declared on
|
||||
a dependency will not be applied when the dependency can be reached through a different
|
||||
path. For example, if a starter POM declares the following:
|
||||
@ -296,7 +296,7 @@ which does not have an `exclusion` element.
|
||||
|
||||
To ensure that correct exclusions are actually applied, the Spring Boot Gradle plugin will
|
||||
automatically add exclusion rules. All exclusions defined in the
|
||||
`spring-boot-dependencies` POM and implicit rules for the ``starter'' POMs will be added.
|
||||
`spring-boot-dependencies` POM and implicit rules for the "`starter`" POMs will be added.
|
||||
|
||||
If you don't want exclusion rules automatically applied you can use the following
|
||||
configuration:
|
||||
@ -331,7 +331,7 @@ To build and run a project artifact, you can type the following:
|
||||
|
||||
To build a war file that is both executable and deployable into an external container,
|
||||
you need to mark the embedded container dependencies as belonging to a configuration
|
||||
named ``providedRuntime'', e.g:
|
||||
named "`providedRuntime`", e.g:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,attributes"]
|
||||
----
|
||||
@ -362,7 +362,7 @@ named ``providedRuntime'', e.g:
|
||||
|
||||
[[build-tool-plugins-gradle-running-applications]]
|
||||
=== Running a project in-place
|
||||
To run a project in place without building a jar first you can use the ``bootRun'' task:
|
||||
To run a project in place without building a jar first you can use the "`bootRun`" task:
|
||||
|
||||
[indent=0]
|
||||
----
|
||||
@ -513,7 +513,7 @@ The following configuration options are available:
|
||||
(defaults to a guess based on the archive type).
|
||||
|
||||
|`requiresUnpack`
|
||||
|A list of dependencies (in the form ``groupId:artifactId'' that must be unpacked from
|
||||
|A list of dependencies (in the form "`groupId:artifactId`" that must be unpacked from
|
||||
fat jars in order to run. Items are still packaged into the fat jar, but they will be
|
||||
automatically unpacked when it runs.
|
||||
|===
|
||||
@ -573,7 +573,7 @@ you may find that it includes unnecessary dependencies.
|
||||
If you want to use a build tool other than Maven or Gradle, you will likely need to develop
|
||||
your own plugin. Executable jars need to follow a specific format and certain entries need
|
||||
to be written in an uncompressed form (see the
|
||||
'<<appendix-executable-jar-format.adoc#executable-jar, executable jar format>>' section
|
||||
_<<appendix-executable-jar-format.adoc#executable-jar, executable jar format>>_ section
|
||||
in the appendix for details).
|
||||
|
||||
The Spring Boot Maven and Gradle plugins both make use of `spring-boot-loader-tools` to
|
||||
@ -637,4 +637,4 @@ technical details of the <<appendix-executable-jar-format.adoc#executable-jar, e
|
||||
jar format>> are covered in the appendix.
|
||||
|
||||
If you have specific build-related questions you can check out the
|
||||
`<<howto.adoc#howto, how-to>>' guides.
|
||||
"`<<howto.adoc#howto, how-to>>`" guides.
|
||||
|
||||
@ -5,11 +5,11 @@
|
||||
--
|
||||
Spring Boot's executable jars are ready-made for most popular cloud PaaS
|
||||
(platform-as-a-service) providers. These providers tend to require that you
|
||||
_`bring your own container'_; they manage application processes (not Java applications
|
||||
"`bring your own container`"; they manage application processes (not Java applications
|
||||
specifically), so they need some intermediary layer that adapts _your_ application to the
|
||||
_cloud's_ notion of a running process.
|
||||
|
||||
Two popular cloud providers, Heroku and Cloud Foundry, employ a ``buildpack'' approach.
|
||||
Two popular cloud providers, Heroku and Cloud Foundry, employ a "`buildpack`" approach.
|
||||
The buildpack wraps your deployed code in whatever is needed to _start_ your
|
||||
application: it might be a JDK and a call to `java`, it might be an embedded webserver,
|
||||
or it might be a full-fledged application server. A buildpack is pluggable, but ideally
|
||||
@ -22,7 +22,7 @@ to run packaged within it.
|
||||
|
||||
In this section we'll look at what it takes to get the
|
||||
<<getting-started.adoc#getting-started-first-application, simple application that we
|
||||
developed>> in the ``Getting Started'' section up and running in the Cloud.
|
||||
developed>> in the "`Getting Started`" section up and running in the Cloud.
|
||||
--
|
||||
|
||||
|
||||
@ -226,7 +226,7 @@ Your application should now be up and running on Heroku.
|
||||
|
||||
[[cloud-deployment-cloudbees]]
|
||||
== CloudBees
|
||||
CloudBees provides cloud-based ``continuous integration'' and ``continuous delivery''
|
||||
CloudBees provides cloud-based "`continuous integration`" and "`continuous delivery`"
|
||||
services as well as Java PaaS hosting. https://github.com/msgilligan[Sean Gilligan]
|
||||
has contributed an excellent
|
||||
https://github.com/CloudBees-community/springboot-gradle-cloudbees-sample[Spring Boot
|
||||
@ -308,9 +308,9 @@ features that a PaaS can offer. These are just three of the most popular Java Pa
|
||||
providers, since Spring Boot is so amenable to cloud-based deployment you're free to
|
||||
consider other providers as well.
|
||||
|
||||
The next section goes on to cover the '<<spring-boot-cli.adoc#cli, Spring Boot CLI>>';
|
||||
The next section goes on to cover the _<<spring-boot-cli.adoc#cli, Spring Boot CLI>>_;
|
||||
or you can jump ahead to read about
|
||||
'<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>'.
|
||||
_<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>_.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
[partintro]
|
||||
--
|
||||
If you're just getting started with Spring Boot, or 'Spring' in general, this is the section
|
||||
for you! Here we answer the basic '``what?''', '``how?''' and '``why?''' questions. You'll
|
||||
for you! Here we answer the basic '"`what?`"', '"`how?`"' and '"`why?`"' questions. You'll
|
||||
find a gentle introduction to Spring Boot along with installation instructions.
|
||||
We'll then build our first Spring Boot application, discussing some core principles as
|
||||
we go.
|
||||
@ -14,13 +14,13 @@ we go.
|
||||
[[getting-started-introducing-spring-boot]]
|
||||
== Introducing Spring Boot
|
||||
Spring Boot makes it easy to create stand-alone, production-grade Spring based
|
||||
Applications that you can ``just run''. We take an opinionated view of the Spring
|
||||
Applications that you can "`just run`". We take an opinionated view of the Spring
|
||||
platform and third-party libraries so you can get started with minimum fuss. Most Spring
|
||||
Boot applications need very little Spring configuration.
|
||||
|
||||
You can use Spring Boot to create Java applications that can be started using `java -jar`
|
||||
or more traditional war deployments. We also provide a command line tool that runs
|
||||
``spring scripts''.
|
||||
"`spring scripts`".
|
||||
|
||||
Our primary goals are:
|
||||
|
||||
@ -36,7 +36,7 @@ diverge from the defaults.
|
||||
|
||||
[[getting-started-installing-spring-boot]]
|
||||
== Installing Spring Boot
|
||||
Spring Boot can be used with ``classic'' Java development tools or installed as a command
|
||||
Spring Boot can be used with "`classic`" Java development tools or installed as a command
|
||||
line tool. Regardless, you will need http://www.java.com[Java SDK v1.6] or higher. You
|
||||
should check your current Java installation before you begin:
|
||||
|
||||
@ -47,7 +47,7 @@ should check your current Java installation before you begin:
|
||||
|
||||
If you are new to Java development, or if you just want to experiment with Spring Boot
|
||||
you might want to try the <<getting-started-installing-the-cli, Spring Boot CLI>> first,
|
||||
otherwise, read on for ``classic'' installation instructions.
|
||||
otherwise, read on for "`classic`" installation instructions.
|
||||
|
||||
TIP: Although Spring Boot is compatible with Java 1.6, if possible, you should consider
|
||||
using the latest version of Java.
|
||||
@ -78,8 +78,8 @@ OSX Homebrew user try `brew install maven`. Ubuntu users can run
|
||||
|
||||
Spring Boot dependencies use the `org.springframework.boot` `groupId`. Typically your
|
||||
Maven POM file will inherit from the `spring-boot-starter-parent` project and declare
|
||||
dependencies to one or more <<using-spring-boot.adoc#using-boot-starter-poms, ``Starter
|
||||
POMs''>>. Spring Boot also provides an optional
|
||||
dependencies to one or more <<using-spring-boot.adoc#using-boot-starter-poms, "`Starter
|
||||
POMs`">>. Spring Boot also provides an optional
|
||||
<<build-tool-plugins.adoc#build-tool-plugins-maven-plugin, Maven plugin>> to create
|
||||
executable jars.
|
||||
|
||||
@ -164,13 +164,13 @@ installed you can follow the instructions at http://www.gradle.org/.
|
||||
|
||||
Spring Boot dependencies can be declared using the `org.springframework.boot` `group`.
|
||||
Typically your project will declare dependencies to one or more
|
||||
<<using-spring-boot.adoc#using-boot-starter-poms, ``Starter POMs''>>. Spring Boot
|
||||
<<using-spring-boot.adoc#using-boot-starter-poms, "`Starter POMs`">>. Spring Boot
|
||||
provides a useful <<build-tool-plugins.adoc#build-tool-plugins-gradle-plugin, Gradle plugin>>
|
||||
that can be used to simplify dependency declarations and to create executable jars.
|
||||
|
||||
.Gradle Wrapper
|
||||
****
|
||||
The Gradle Wrapper provides a nice way of ``obtaining'' Gradle when you need to build a
|
||||
The Gradle Wrapper provides a nice way of "`obtaining`" Gradle when you need to build a
|
||||
project. It's a small script and library that you commit alongside your code to bootstrap
|
||||
the build process. See http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
|
||||
for details.
|
||||
@ -375,9 +375,9 @@ output:
|
||||
|
||||
[[getting-started-upgrading-from-an-earlier-version]]
|
||||
=== Upgrading from an earlier version of Spring Boot
|
||||
If you are upgrading from an earlier release of Spring Boot check the ``release notes''
|
||||
If you are upgrading from an earlier release of Spring Boot check the "`release notes`"
|
||||
hosted on the {github-wiki}[project wiki]. You'll find upgrade instructions along with
|
||||
a list of ``new and noteworthy'' features for each release.
|
||||
a list of "`new and noteworthy`" features for each release.
|
||||
|
||||
To upgrade an existing CLI installation use the appropriate package manager command
|
||||
(for example `brew upgrade`) or, if you manually installed the CLI, follow the
|
||||
@ -388,11 +388,11 @@ update your `PATH` environment variable to remove any older references.
|
||||
|
||||
[[getting-started-first-application]]
|
||||
== Developing your first Spring Boot application
|
||||
Let's develop a simple ``Hello World!'' web application in Java that highlights some
|
||||
Let's develop a simple "`Hello World!`" web application in Java that highlights some
|
||||
of Spring Boot's key features. We'll use Maven to build this project since most IDEs
|
||||
support it.
|
||||
|
||||
TIP: The http://spring.io[spring.io] web site contains many ``Getting Started'' guides
|
||||
TIP: The http://spring.io[spring.io] web site contains many "`Getting Started`" guides
|
||||
that use Spring Boot. If you're looking to solve a specific problem; check there first.
|
||||
|
||||
Before we begin, open a terminal to check that you have valid versions of Java and Maven
|
||||
@ -415,7 +415,7 @@ installed.
|
||||
----
|
||||
|
||||
NOTE: This sample needs to be created in its own folder. Subsequent instructions assume
|
||||
that you have created a suitable folder and that it is your ``current directory''.
|
||||
that you have created a suitable folder and that it is your "`current directory`".
|
||||
|
||||
|
||||
|
||||
@ -471,7 +471,7 @@ endif::[]
|
||||
----
|
||||
|
||||
This should give you a working build, you can test it out by running `mvn package` (you
|
||||
can ignore the '``jar will be empty - no content was marked for inclusion!''' warning for
|
||||
can ignore the '"`jar will be empty - no content was marked for inclusion!'`"' warning for
|
||||
now).
|
||||
|
||||
NOTE: At this point you could import the project into an IDE (most modern Java IDE's
|
||||
@ -482,13 +482,13 @@ text editor for this example.
|
||||
|
||||
[[getting-started-first-application-dependencies]]
|
||||
=== Adding classpath dependencies
|
||||
Spring Boot provides a number of ``Starter POMs'' that make easy to add jars to your
|
||||
Spring Boot provides a number of "`Starter POMs`" that make easy to add jars to your
|
||||
classpath. Our sample application has already used `spring-boot-starter-parent` in the
|
||||
`parent` section of the POM. The `spring-boot-starter-parent` is a special starter
|
||||
that provides useful Maven defaults. It also provides a `dependency-management` section
|
||||
so that you can omit `version` tags for ``blessed'' dependencies.
|
||||
so that you can omit `version` tags for "`blessed`" dependencies.
|
||||
|
||||
Other ``Starter POMs'' simply provide dependencies that you are likely to need when
|
||||
Other "`Starter POMs`" simply provide dependencies that you are likely to need when
|
||||
developing a specific type of application. Since we are developing a web application, we
|
||||
will add a `spring-boot-starter-web` dependency -- but before that, let's look at what we
|
||||
currently have.
|
||||
@ -561,7 +561,7 @@ _stereotype_ annotation. It provides hints for people reading the code, and for
|
||||
that the class plays a specific role. In this case, our class is a web `@Controller` so
|
||||
Spring will consider it when handling incoming web requests.
|
||||
|
||||
The `@RequestMapping` annotation provides ``routing'' information. It is telling Spring
|
||||
The `@RequestMapping` annotation provides "`routing`" information. It is telling Spring
|
||||
that any HTTP request with the path "`/`" should be mapped to the `home` method. The
|
||||
`@RestController` annotation tells Spring to render the resulting string directly
|
||||
back to the caller.
|
||||
@ -576,14 +576,14 @@ Reference Documentation for more details.
|
||||
[[getting-started-first-application-auto-configuration]]
|
||||
==== The @EnableAutoConfiguration annotation
|
||||
The second class-level annotation is `@EnableAutoConfiguration`. This annotation tells
|
||||
Spring Boot to ``guess'' how you will want to configure Spring, based on the jar
|
||||
Spring Boot to "`guess`" how you will want to configure Spring, based on the jar
|
||||
dependencies that you have added. Since `spring-boot-starter-web` added Tomcat and
|
||||
Spring MVC, the auto-configuration will assume that you are developing a web application
|
||||
and setup Spring accordingly.
|
||||
|
||||
.Starter POMs and Auto-Configuration
|
||||
****
|
||||
Auto-configuration is designed to work well with ``Starter POMs'', but the two concepts
|
||||
Auto-configuration is designed to work well with "`Starter POMs`", but the two concepts
|
||||
are not directly tied. You are free to pick-and-choose jar dependencies outside of the
|
||||
starter POMs and Spring Boot will still do its best to auto-configure your application.
|
||||
****
|
||||
@ -591,7 +591,7 @@ starter POMs and Spring Boot will still do its best to auto-configure your appli
|
||||
|
||||
|
||||
[[getting-started-first-application-main-method]]
|
||||
==== The ``main'' method
|
||||
==== The "`main`" method
|
||||
The final part of our application is the `main` method. This is just a standard method
|
||||
that follows the Java convention for an application entry point. Our main method delegates
|
||||
to Spring Boot's `SpringApplication` class by calling `run`. `SpringApplication` will
|
||||
@ -640,7 +640,7 @@ To gracefully exit the application hit `ctrl-c`.
|
||||
[[getting-started-first-application-executable-jar]]
|
||||
=== Creating an executable jar
|
||||
Let's finish our example by creating a completely self-contained executable jar file that
|
||||
we could run in production. Executable jars (sometimes called ``fat jars'') are archives
|
||||
we could run in production. Executable jars (sometimes called "`fat jars`") are archives
|
||||
containing your compiled classes along with all of the jar dependencies that your code
|
||||
needs to run.
|
||||
|
||||
@ -650,8 +650,8 @@ Java does not provide any standard way to load nested jar files (i.e. jar files
|
||||
themselves contained within a jar). This can be problematic if you are looking to
|
||||
distribute a self-contained application.
|
||||
|
||||
To solve this problem, many developers use ``shaded'' jars. A shaded jar simply packages
|
||||
all classes, from all jars, into a single ``uber jar''. The problem with shaded jars is that
|
||||
To solve this problem, many developers use "`shaded`" jars. A shaded jar simply packages
|
||||
all classes, from all jars, into a single "`uber jar`". The problem with shaded jars is that
|
||||
it becomes hard to see which libraries you are actually using in your application. It can
|
||||
also be problematic if the the same filename is used (but with different content) in
|
||||
multiple jars.
|
||||
@ -742,9 +742,9 @@ Hopefully this section has provided you with some of the Spring Boot basics, and
|
||||
on your way to writing your own applications. If you're a task-oriented type of
|
||||
developer you might want to jump over to http://spring.io and check out some of the
|
||||
http://spring.io/guides/[getting started] guides that solve specific
|
||||
'``How do I do that with Spring''' problems; we also have Spring Boot-specific
|
||||
'<<howto.adoc#howto, How-to>>' reference documentation.
|
||||
"`How do I do that with Spring`" problems; we also have Spring Boot-specific
|
||||
_<<howto.adoc#howto, How-to>>_ reference documentation.
|
||||
|
||||
Otherwise, the next logical step is to read '<<using-spring-boot.adoc#using-boot>>'. If
|
||||
Otherwise, the next logical step is to read _<<using-spring-boot.adoc#using-boot>>_. If
|
||||
you're really impatient, you could also jump ahead and read about
|
||||
'<<spring-boot-features.adoc#boot-features, Spring Boot features>>'.
|
||||
_<<spring-boot-features.adoc#boot-features, Spring Boot features>>_.
|
||||
|
||||
@ -41,7 +41,7 @@ rules of thumb:
|
||||
`+@Conditional*+` annotations to find out what features they enable and when. Add
|
||||
`--debug` to the command line or a System property `-Ddebug` to get a log on the
|
||||
console of all the autoconfiguration decisions that were made in your app. In a running
|
||||
Actuator app look at the `autoconfig` endpoint (`/autoconfig' or the JMX equivalent) for
|
||||
Actuator app look at the `autoconfig` endpoint ('`/autoconfig`' or the JMX equivalent) for
|
||||
the same information.
|
||||
* Look for classes that are `@ConfigurationProperties` (e.g.
|
||||
{sc-spring-boot-autoconfigure}/web/ServerProperties.{sc-ext}[`ServerProperties`])
|
||||
@ -79,7 +79,7 @@ than one way to register additional ones:
|
||||
The `SpringApplication` sends some special `ApplicationEvents` to the listeners (even
|
||||
some before the context is created), and then registers the listeners for events published
|
||||
by the `ApplicationContext` as well. See
|
||||
'<<spring-boot-features.adoc#boot-features-application-events-and-listeners>>' in the
|
||||
_<<spring-boot-features.adoc#boot-features-application-events-and-listeners>>_ in the
|
||||
'`Spring Boot features`' section for a complete list.
|
||||
|
||||
|
||||
@ -87,7 +87,7 @@ by the `ApplicationContext` as well. See
|
||||
[[howto-build-an-application-context-hierarchy]]
|
||||
=== Build an ApplicationContext hierarchy (adding a parent or root context)
|
||||
You can use the `ApplicationBuilder` class to create parent/child `ApplicationContext`
|
||||
hierarchies. See '<<spring-boot-features.adoc#boot-features-fluent-builder-api>>'
|
||||
hierarchies. See _<<spring-boot-features.adoc#boot-features-fluent-builder-api>>_
|
||||
in the '`Spring Boot features`' section for more information.
|
||||
|
||||
|
||||
@ -135,7 +135,7 @@ underscores (`_`) as well as dashes (`-`) in property names.
|
||||
[[howto-change-the-location-of-external-properties]]
|
||||
=== Change the location of external properties of an application
|
||||
By default properties from different sources are added to the Spring `Environment` in a
|
||||
defined order (see '<<spring-boot-features.adoc#boot-features-external-config>>' in
|
||||
defined order (see _<<spring-boot-features.adoc#boot-features-external-config>>_ in
|
||||
the '`Spring Boot features`' section for the exact order).
|
||||
|
||||
A nice way to augment and modify this is to add `@PropertySource` annotations to your
|
||||
@ -222,7 +222,7 @@ The example YAML above corresponds to an `application.properties` file
|
||||
server.port=9000
|
||||
----
|
||||
|
||||
See '<<spring-boot-features.adoc#boot-features-external-config-yaml>>' in
|
||||
See _<<spring-boot-features.adoc#boot-features-external-config-yaml>>_ in
|
||||
the '`Spring Boot features`' section for more information
|
||||
about YAML.
|
||||
|
||||
@ -249,7 +249,7 @@ A value set this way is replaced by the System property or environment variable
|
||||
but not by the `SpringApplicationBuilder.profiles()` method. Thus the latter Java API can
|
||||
be used to augment the profiles without changing the defaults.
|
||||
|
||||
See '<<spring-boot-features.adoc#boot-features-profiles>>' in
|
||||
See _<<spring-boot-features.adoc#boot-features-profiles>>_ in
|
||||
the '`Spring Boot features`' section for more information.
|
||||
|
||||
|
||||
@ -345,7 +345,7 @@ environment variable).
|
||||
To switch off the HTTP endpoints completely, but still create a `WebApplicationContext`,
|
||||
use `server.port=-1` (this is sometimes useful for testing).
|
||||
|
||||
For more details look at '<<spring-boot-features.adoc#boot-features-customizing-embedded-containers>>'
|
||||
For more details look at _<<spring-boot-features.adoc#boot-features-customizing-embedded-containers>>_
|
||||
in the '`Spring Boot features`' section, or the
|
||||
{sc-spring-boot-autoconfigure}/web/ServerProperties.{sc-ext}[`ServerProperties`] source
|
||||
code.
|
||||
@ -365,7 +365,7 @@ that and be sure that it has initialized is to add a `@Bean` of type
|
||||
`ApplicationListener<EmbeddedServletContainerInitializedEvent>` and pull the container
|
||||
out of the event when it is published.
|
||||
|
||||
A useful practice for use with `@IntegrationTest`s is to set `server.port=0`
|
||||
A useful practice for use with `@IntegrationTests` is to set `server.port=0`
|
||||
and then inject the actual ('`local`') port as a `@Value`. For example:
|
||||
|
||||
[source,java,indent=0,subs="verbatim,quotes,attributes"]
|
||||
@ -413,7 +413,7 @@ accessible on the filesystem, i.e. it cannot be read from within a jar file.
|
||||
[[howto-configure-tomcat]]
|
||||
=== Configure Tomcat
|
||||
Generally you can follow the advice from
|
||||
'<<howto-discover-build-in-options-for-external-properties>>' about
|
||||
_<<howto-discover-build-in-options-for-external-properties>>_ about
|
||||
`@ConfigurationProperties` (`ServerProperties` is the main one here), but also look at
|
||||
`EmbeddedServletContainerCustomizer` and various Tomcat-specific `+*Customizers+` that you
|
||||
can add in one of those. The Tomcat APIs are quite rich so once you have access to the
|
||||
@ -548,7 +548,7 @@ Example in Gradle:
|
||||
[[howto-configure-jetty]]
|
||||
=== Configure Jetty
|
||||
Generally you can follow the advice from
|
||||
'<<howto-discover-build-in-options-for-external-properties>>' about
|
||||
_<<howto-discover-build-in-options-for-external-properties>>_ about
|
||||
`@ConfigurationProperties` (`ServerProperties` is the main one here), but also look at
|
||||
`EmbeddedServletContainerCustomizer`. The Jetty APIs are quite rich so once you have
|
||||
access to the `JettyEmbeddedServletContainerFactory` you can modify it in a number
|
||||
@ -689,7 +689,7 @@ provided of type `HttpMessageConverters` (always available if you use the defaul
|
||||
configuration) which has some useful methods to access the default and user-enhanced
|
||||
message converters.
|
||||
|
||||
See also the '<<howto-customize-the-responsebody-rendering>>' section and the
|
||||
See also the _<<howto-customize-the-responsebody-rendering>>_ section and the
|
||||
{sc-spring-boot-autoconfigure}/web/WebMvcAutoConfiguration.{sc-ext}[`WebMvcAutoConfiguration`]
|
||||
source code for more details.
|
||||
|
||||
@ -964,7 +964,7 @@ your own, and bind it to a set of `Environment` properties e.g.
|
||||
datasource.mine.poolSize=30
|
||||
----
|
||||
|
||||
See '<<spring-boot-features.adoc#boot-features-configure-datasource>>' in the
|
||||
See _<<spring-boot-features.adoc#boot-features-configure-datasource>>_ in the
|
||||
'`Spring Boot features`' section and the
|
||||
{sc-spring-boot-autoconfigure}/jdbc/DataSourceAutoConfiguration.{sc-ext}[`DataSourceAutoConfiguration`]
|
||||
class for more details.
|
||||
@ -1314,7 +1314,7 @@ also set `management.address` to a valid IP address that the server is able to b
|
||||
For more detail look at the
|
||||
{sc-spring-boot-actuator}/autoconfigure/ManagementServerProperties.{sc-ext}[`ManagementServerProperties`]
|
||||
source code and
|
||||
'<<production-ready-features.adoc#production-ready-customizing-management-server-port>>'
|
||||
_<<production-ready-features.adoc#production-ready-customizing-management-server-port>>_
|
||||
in the '`Production-ready features`' section.
|
||||
|
||||
|
||||
|
||||
@ -131,7 +131,7 @@ of the `beans` endpoint and also enables `shutdown`.
|
||||
endpoints.shutdown.enabled=true
|
||||
----
|
||||
|
||||
NOTE: The prefix "`endpoints` + `.` + `name`" is used to uniquely identify the endpoint
|
||||
NOTE: The prefix ‟`endpoints` + `.` + `name`” is used to uniquely identify the endpoint
|
||||
that is being configured.
|
||||
|
||||
|
||||
@ -846,4 +846,4 @@ might want to read about graphing tools such as http://graphite.wikidot.com/[Gra
|
||||
Otherwise, you can continue on, to read about <<cloud-deployment.adoc#cloud-deployment,
|
||||
'`cloud deployment options`'>> or jump ahead
|
||||
for some in-depth information about Spring Boot's
|
||||
'<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>'.
|
||||
_<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>_.
|
||||
|
||||
@ -14,8 +14,8 @@ familiar Java-like syntax, without so much boilerplate code.
|
||||
== Installing the CLI
|
||||
The Spring Boot CLI can be installed manually; using GVM (the Groovy Environment
|
||||
Manually) or using Homebrew if you are an OSX user. See
|
||||
'<<getting-started.adoc#getting-started-installing-the-cli>>'
|
||||
in the ``Getting started'' section for comprehensive installation instructions.
|
||||
_<<getting-started.adoc#getting-started-installing-the-cli>>_
|
||||
in the "`Getting started`" section for comprehensive installation instructions.
|
||||
|
||||
|
||||
|
||||
@ -78,7 +78,7 @@ using.
|
||||
You can compile and run Groovy source code using the `run` command. The Spring Boot CLI
|
||||
is completely self-contained so you don't need any external Groovy installation.
|
||||
|
||||
Here is an example ``hello world'' web application written in Groovy:
|
||||
Here is an example "`hello world`" web application written in Groovy:
|
||||
|
||||
[source,groovy,indent=0,subs="verbatim,quotes,attributes"]
|
||||
----
|
||||
@ -96,16 +96,16 @@ Here is an example ``hello world'' web application written in Groovy:
|
||||
|
||||
|
||||
[[cli-deduced-grab-annotations]]
|
||||
==== Deduced ``grab'' dependencies
|
||||
==== Deduced "`grab`" dependencies
|
||||
Standard Groovy includes a `@Grab` annotation which allows you to declare dependencies
|
||||
on a third-party libraries. This useful technique allows Groovy to download jars in the
|
||||
same way as Maven or Gradle would; but without requiring you to use a build tool.
|
||||
|
||||
Spring Boot extends this technique further, and will attempt to deduce which libraries
|
||||
to ``grab'' based on your code. For example, since the `WebApplication` code above uses
|
||||
`@RestController` annotations, ``Tomcat'' and ``Spring MVC'' will be grabbed.
|
||||
to "`grab`" based on your code. For example, since the `WebApplication` code above uses
|
||||
`@RestController` annotations, "`Tomcat`" and "`Spring MVC`" will be grabbed.
|
||||
|
||||
The following items are used as ``grab hints'':
|
||||
The following items are used as "`grab hints`":
|
||||
|
||||
|===
|
||||
| Items | Grabs
|
||||
@ -154,7 +154,7 @@ in the Spring Boot CLI source code to understand exactly how customizations are
|
||||
|
||||
|
||||
[[cli-default-grab-deduced-coordinates]]
|
||||
==== Deduced ``grab'' coordinates
|
||||
==== Deduced "`grab`" coordinates
|
||||
Spring Boot extends Groovy's standard `@Grab` support by allowing you to specify a dependency
|
||||
without a group or version, for example `@Grab('freemarker')`. This will consult Spring Boot's
|
||||
default dependency metadata to deduce the artifact's group and version. Note that the default
|
||||
@ -166,12 +166,12 @@ metadata can be found in the <<appendix-dependency-versions, appendix>>.
|
||||
|
||||
|
||||
[[cli-default-grab-deduced-coordinates-custom-metadata]]
|
||||
===== Custom ``grab'' metadata
|
||||
===== Custom "`grab`" metadata
|
||||
Spring Boot provides a new annotation, `@GrabMetadata` that can be used to provide custom
|
||||
dependency metadata that overrides Spring Boot's defaults. This metadata is specified by
|
||||
using this annotation to provide the coordinates of one or more properties files (deployed
|
||||
using this annotation to provide the coordinates of one or more properties files (deployed
|
||||
to a Maven repository with a "type" identifier: "properties"). For example
|
||||
`@GrabMetadata(['com.example:versions-one:1.0.0', 'com.example.versions-two:1.0.0'])` will
|
||||
`@GrabMetadata(['com.example:versions-one:1.0.0', 'com.example.versions-two:1.0.0'])` will
|
||||
pick up files in a Maven repository in "com/example/versions-*/1.0.0/versions-*-1.0.0.properties". The
|
||||
properties files are applied in the order that they're specified. In the example above, this
|
||||
means that properties in `versions-two` will override properties in `versions-one`. Each entry
|
||||
@ -241,7 +241,7 @@ into a `test` directory.
|
||||
|
||||
[[cli-multiple-source-files]]
|
||||
=== Applications with multiple source files
|
||||
You can use ``shell globbing'' with all commands that accept file input. This allows you
|
||||
You can use "`shell globbing`" with all commands that accept file input. This allows you
|
||||
to easily use multiple files from a single directory, e.g.
|
||||
|
||||
[indent=0]
|
||||
@ -249,7 +249,7 @@ to easily use multiple files from a single directory, e.g.
|
||||
$ spring run *.groovy
|
||||
----
|
||||
|
||||
This technique can also be useful if you want to segregate your ``test'' or ``spec'' code
|
||||
This technique can also be useful if you want to segregate your "`test`" or "`spec`" code
|
||||
from the main application code:
|
||||
|
||||
[indent=0]
|
||||
@ -273,7 +273,7 @@ The resulting jar will contain the classes produced by compiling the application
|
||||
of the application's dependencies so that it can then be run using `java -jar`. The jar
|
||||
file will also contain entries from the application's classpath. You can add explicit
|
||||
paths to the jar using `--include` and `--exclude` (both are comma-separated, and both
|
||||
accept prefixes to the values ``+'' and ``-'' to signify that they should be removed from
|
||||
accept prefixes to the values "`+`" and "`-`" to signify that they should be removed from
|
||||
the defaults). The default includes are
|
||||
|
||||
[indent=0]
|
||||
@ -319,7 +319,7 @@ embedded shell.
|
||||
|
||||
[[cli-groovy-beans-dsl]]
|
||||
== Developing application with the Groovy beans DSL
|
||||
Spring Framework 4.0 has native support for a `beans{}` ``DSL'' (borrowed from
|
||||
Spring Framework 4.0 has native support for a `beans{}` "`DSL`" (borrowed from
|
||||
http://grails.org/[Grails]), and you can embed bean definitions in your Groovy
|
||||
application scripts using the same format. This is sometimes a good way to include
|
||||
external features like middleware declarations. For example:
|
||||
@ -361,7 +361,7 @@ Spring Boot CLI. There is also extensive javadoc throughout the
|
||||
{sc-spring-boot-cli}[source code].
|
||||
|
||||
If you find that you reach the limit of the CLI tool, you will probably want to look
|
||||
at converting your application to full Gradle or Maven built ``groovy project''. The
|
||||
at converting your application to full Gradle or Maven built "`groovy project`". The
|
||||
next section covers Spring Boot's
|
||||
'<<build-tool-plugins.adoc#build-tool-plugins, Build tool plugins>>' that you can
|
||||
_<<build-tool-plugins.adoc#build-tool-plugins, Build tool plugins>>_ that you can
|
||||
use with Gradle or Maven.
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
--
|
||||
This section dives into the details of Spring Boot. Here you can learn about the key
|
||||
features that you will want to use and customize. If you haven't already, you might want
|
||||
to read the '<<getting-started.adoc#getting-started>>' and
|
||||
'<<using-spring-boot.adoc#using-boot>>' sections so that you have a good grounding
|
||||
to read the _<<getting-started.adoc#getting-started>>_ and
|
||||
_<<using-spring-boot.adoc#using-boot>>_ sections so that you have a good grounding
|
||||
of the basics.
|
||||
--
|
||||
|
||||
@ -73,7 +73,7 @@ for spring beans. In most cases these will be references to `@Configuration` cla
|
||||
they could also be references to XML configuration or to packages that should be scanned.
|
||||
|
||||
It is also possible to configure the `SpringApplication` using an `application.properties`
|
||||
file. See '<<boot-features-external-config>>' for details.
|
||||
file. See _<<boot-features-external-config>>_ for details.
|
||||
|
||||
For a complete list of the configuration options, see the
|
||||
{dc-spring-boot}/SpringApplication.{dc-ext}[`SpringApplication` Javadoc].
|
||||
@ -341,7 +341,7 @@ properties).
|
||||
----
|
||||
|
||||
TIP: You can also use this technique to create '`short`' variants of existing Spring Boot
|
||||
properties. See the '<<howto.adoc#howto-use-short-command-line-arguments>>' how-to
|
||||
properties. See the _<<howto.adoc#howto-use-short-command-line-arguments>>_ how-to
|
||||
for details.
|
||||
|
||||
|
||||
@ -369,7 +369,7 @@ For example, the following YAML document:
|
||||
[source,yaml,indent=0]
|
||||
----
|
||||
environments:
|
||||
dev:`
|
||||
dev:
|
||||
url: http://dev.bar.com
|
||||
name: Developer Setup
|
||||
prod:
|
||||
@ -583,7 +583,7 @@ You can also add a custom Spring `Validator` by creating a bean definition calle
|
||||
TIP: The `spring-boot-actuator` module includes an endpoint that exposes all
|
||||
`@ConfigurationProperties` beans. Simply point your web browser to `/configprops`
|
||||
or use the equivalent JMX endpoint. See the
|
||||
'<<production-ready-features.adoc#production-ready-endpoints, Production ready features>>'.
|
||||
_<<production-ready-features.adoc#production-ready-endpoints, Production ready features>>_.
|
||||
section for details.
|
||||
|
||||
|
||||
@ -661,7 +661,7 @@ possible to activate profiles using Spring's `ConfigurableEnvironment` interface
|
||||
=== Profile specific configuration files
|
||||
Profile specific variants of both `application.properties` (or `application.yml`) and
|
||||
files referenced via `@ConfigurationProperties` are considered as files are loaded.
|
||||
See '<<boot-features-external-config-profile-specific-properties>>' for details.
|
||||
See _<<boot-features-external-config-profile-specific-properties>>_ for details.
|
||||
|
||||
|
||||
|
||||
@ -812,7 +812,7 @@ use the `spring-boot-starter-web` module to get up and running quickly.
|
||||
|
||||
If you haven't yet developed a Spring Boot web application you can follow the
|
||||
"Hello World!" example in the
|
||||
'<<getting-started.adoc#getting-started-first-application, Getting started>>' section.
|
||||
_<<getting-started.adoc#getting-started-first-application, Getting started>>_ section.
|
||||
|
||||
|
||||
|
||||
@ -1406,7 +1406,7 @@ considered. A typical entity class would look something like this:
|
||||
----
|
||||
|
||||
TIP: You can customize entity scanning locations using the `@EntityScan` annotation.
|
||||
See the '<<howto.adoc#howto-separate-entity-definitions-from-spring-configuration>>'
|
||||
See the _<<howto.adoc#howto-separate-entity-definitions-from-spring-configuration>>_
|
||||
how-to.
|
||||
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ recommendations that, when followed, will make your development process just a
|
||||
little easier.
|
||||
|
||||
If you're just starting out with Spring Boot, you should probably read the
|
||||
'<<getting-started.adoc#getting-started, Getting Started>>' guide before diving into
|
||||
_<<getting-started.adoc#getting-started, Getting Started>>_ guide before diving into
|
||||
this section.
|
||||
--
|
||||
|
||||
@ -21,7 +21,7 @@ this section.
|
||||
[[using-boot-build-systems]]
|
||||
== Build systems
|
||||
It is strongly recommended that you choose a build system that supports _dependency
|
||||
management_, and one that can consume artifacts published to the ``Maven Central''
|
||||
management_, and one that can consume artifacts published to the "`Maven Central`"
|
||||
repository. We would recommend that you choose Maven or Gradle. It is possible to get
|
||||
Spring Boot to work with other build systems (Ant for example), but they will not be
|
||||
particularly well supported.
|
||||
@ -134,8 +134,8 @@ the parent.
|
||||
|
||||
[[using-boot-gradle]]
|
||||
=== Gradle
|
||||
Gradle users can directly import ``starter POMs'' in their `dependencies` section. Unlike
|
||||
Maven, there is no ``super parent'' to import to share some configuration.
|
||||
Gradle users can directly import "`starter POMs`" in their `dependencies` section. Unlike
|
||||
Maven, there is no "`super parent`" to import to share some configuration.
|
||||
|
||||
[source,groovy,indent=0,subs="attributes"]
|
||||
----
|
||||
@ -151,7 +151,7 @@ The <<build-tool-plugins.adoc#build-tool-plugins-gradle-plugin, `spring-boot-gra
|
||||
is also available and provides tasks to create executable jars and run projects from
|
||||
source. It also adds a `ResolutionStrategy` that enables you to
|
||||
<<build-tool-plugins-gradle-dependencies-without-versions, omit the version number
|
||||
for ``blessed'' dependencies>>:
|
||||
for "`blessed`" dependencies>>:
|
||||
|
||||
[source,groovy,indent=0,subs="attributes"]
|
||||
----
|
||||
@ -180,7 +180,7 @@ It is possible to build a Spring Boot project using Apache Ant, however, no spec
|
||||
support or plugins are provided. Ant scripts can use the Ivy dependency system to import
|
||||
starter POMs.
|
||||
|
||||
See the '<<howto.adoc#howto-build-an-executable-archive-with-ant>>' ``How-to'' for more
|
||||
See the _<<howto.adoc#howto-build-an-executable-archive-with-ant>>_ "`How-to`" for more
|
||||
complete instructions.
|
||||
|
||||
|
||||
@ -217,13 +217,13 @@ The following application starters are provided by Spring Boot under the
|
||||
|The core Spring Boot starter, including auto-configuration support, logging and YAML.
|
||||
|
||||
|`spring-boot-starter-amqp`
|
||||
|Support for the ``Advanced Message Queuing Protocol'' via `spring-rabbit`.
|
||||
|Support for the "`Advanced Message Queuing Protocol`" via `spring-rabbit`.
|
||||
|
||||
|`spring-boot-starter-aop`
|
||||
|Support for aspect-oriented programming including `spring-aop` and AspectJ.
|
||||
|
||||
|`spring-boot-starter-batch`
|
||||
|Support for ``Spring Batch'' including HSQLDB database.
|
||||
|Support for "`Spring Batch`" including HSQLDB database.
|
||||
|
||||
|`spring-boot-starter-data-elasticsearch`
|
||||
|Support for the Elasticsearch search and analytics engine including
|
||||
@ -233,7 +233,7 @@ The following application starters are provided by Spring Boot under the
|
||||
|Support for the GemFire distributed data store including `spring-data-gemfire`.
|
||||
|
||||
|`spring-boot-starter-data-jpa`
|
||||
|Support for the ``Java Persistence API'' including `spring-data-jpa`, `spring-orm`
|
||||
|Support for the "`Java Persistence API`" including `spring-data-jpa`, `spring-orm`
|
||||
and Hibernate.
|
||||
|
||||
|`spring-boot-starter-data-mongodb`
|
||||
@ -252,7 +252,7 @@ and Hibernate.
|
||||
|Support for the Groovy templating engine
|
||||
|
||||
|`spring-boot-starter-hornetq`
|
||||
|Support for ``Java Message Service API'' via HornetQ.
|
||||
|Support for "`Java Message Service API`" via HornetQ.
|
||||
|
||||
|`spring-boot-starter-integration`
|
||||
|Support for common `spring-integration` modules.
|
||||
@ -299,7 +299,7 @@ and Hibernate.
|
||||
|===
|
||||
|
||||
In addition to the application starters, the following starters can be used to
|
||||
add '<<production-ready-features.adoc#production-ready, production ready>>' features.
|
||||
add _<<production-ready-features.adoc#production-ready, production ready>>_ features.
|
||||
|
||||
.Spring Boot production ready starters
|
||||
|===
|
||||
@ -346,9 +346,9 @@ best practices that help.
|
||||
|
||||
|
||||
[[using-boot-using-the-default-package]]
|
||||
=== Using the ``default'' package
|
||||
=== Using the "`default`" package
|
||||
When a class doesn't include a `package` declaration it is considered to be in the
|
||||
``default package''. The use of the ``default package'' is generally discouraged, and
|
||||
"`default package`". The use of the "`default package`" is generally discouraged, and
|
||||
should be avoided. It can cause particular problems for Spring Boot applications that
|
||||
use `@ComponentScan` or `@EntityScan` annotations, since every class from every jar,
|
||||
will be read.
|
||||
@ -362,7 +362,7 @@ and use a reversed domain name (for example, `com.example.project`).
|
||||
=== Locating the main application class
|
||||
We generally recommend that you locate your main application class in a root package
|
||||
above other classes. The `@EnableAutoConfiguration` annotation is often placed on your
|
||||
main class, and it implicitly defines a base ``search package'' for certain items. For
|
||||
main class, and it implicitly defines a base "`search package`" for certain items. For
|
||||
example, if you are writing a JPA application, the package of the
|
||||
`@EnableAutoConfiguration` annotated class will be used to search for `@Entity` items.
|
||||
|
||||
@ -554,8 +554,8 @@ http://maven.apache.org/plugins/maven-eclipse-plugin/[Eclipse] and
|
||||
http://maven.apache.org/plugins/maven-idea-plugin/[IDEA]; Gradle offers plugins
|
||||
for http://www.gradle.org/docs/current/userguide/ide_support.html[various IDEs].
|
||||
|
||||
TIP: If you accidentally run a web application twice you will see a ``Port already in
|
||||
use'' error. STS users can use the `Relaunch` button rather than `Run` to ensure that
|
||||
TIP: If you accidentally run a web application twice you will see a "`Port already in
|
||||
use`" error. STS users can use the `Relaunch` button rather than `Run` to ensure that
|
||||
any existing instance is closed.
|
||||
|
||||
|
||||
@ -585,7 +585,7 @@ This allows you to attach a debugger to your packaged application:
|
||||
=== Using the Maven plugin
|
||||
The Spring Boot Maven plugin includes a `run` goal which can be used to quickly compile
|
||||
and run your application. Applications run in an exploded form, and you can edit
|
||||
resources for instant ``hot'' reload.
|
||||
resources for instant "`hot`" reload.
|
||||
|
||||
[indent=0,subs="attributes"]
|
||||
----
|
||||
@ -599,7 +599,7 @@ Useful operating system environment variable:
|
||||
$ export MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=128M -Djava.security.egd=file:/dev/./urandom
|
||||
----
|
||||
|
||||
(The ``egd'' setting is to speed up Tomcat startup by giving it a faster source of
|
||||
(The "`egd`" setting is to speed up Tomcat startup by giving it a faster source of
|
||||
entropy for session keys.)
|
||||
|
||||
|
||||
@ -632,7 +632,7 @@ replace, for a more complete solution the
|
||||
https://github.com/spring-projects/spring-loaded[Spring Loaded] project, or
|
||||
http://zeroturnaround.com/software/jrebel/[JRebel] can be used.
|
||||
|
||||
See the <<howto.adoc#howto-hotswapping, Hot swapping ``How-to''>> section for details.
|
||||
See the <<howto.adoc#howto-hotswapping, Hot swapping "`How-to`">> section for details.
|
||||
|
||||
|
||||
|
||||
@ -641,9 +641,9 @@ See the <<howto.adoc#howto-hotswapping, Hot swapping ``How-to''>> section for de
|
||||
Executable jars can be used for production deployment. As they are self-contained, they
|
||||
are also ideally suited for cloud-based deployment.
|
||||
|
||||
For additional ``production ready'' features, such as health, auditing and metric REST
|
||||
For additional "`production ready`" features, such as health, auditing and metric REST
|
||||
or JMX end-points; consider adding `spring-boot-actuator`. See
|
||||
'<<production-ready-features.adoc#production-ready>>' for details.
|
||||
_<<production-ready-features.adoc#production-ready>>_ for details.
|
||||
|
||||
|
||||
|
||||
@ -651,7 +651,7 @@ or JMX end-points; consider adding `spring-boot-actuator`. See
|
||||
== What to read next
|
||||
You should now have good understanding of how you can use Spring Boot along with some best
|
||||
practices that you should follow. You can now go on to learn about specific
|
||||
'<<spring-boot-features#boot-features, Spring Boot features>>' in depth, or you
|
||||
_<<spring-boot-features#boot-features, Spring Boot features>>_ in depth, or you
|
||||
could skip ahead and read about the
|
||||
``<<production-ready-features#production-ready, production ready>>'' aspects of Spring
|
||||
"`<<production-ready-features#production-ready, production ready>>`" aspects of Spring
|
||||
Boot.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user