From 16937746a0e443b2d166471c063ed9daa2d90957 Mon Sep 17 00:00:00 2001 From: Eric Dahl Date: Sun, 12 Oct 2014 12:47:19 -0700 Subject: [PATCH] Fix some grammar issues in docs --- CONTRIBUTING.adoc | 2 +- spring-boot-actuator/README.adoc | 4 +-- .../appendix-application-properties.adoc | 4 +-- .../appendix-executable-jar-format.adoc | 2 +- .../src/main/asciidoc/build-tool-plugins.adoc | 2 +- .../src/main/asciidoc/cloud-deployment.adoc | 4 +-- spring-boot-docs/src/main/asciidoc/howto.adoc | 28 +++++++++---------- .../asciidoc/production-ready-features.adoc | 8 +++--- .../src/main/asciidoc/spring-boot-cli.adoc | 4 +-- .../main/asciidoc/spring-boot-features.adoc | 23 +++++++-------- .../src/main/asciidoc/using-spring-boot.adoc | 4 +-- .../boot/loader/PropertiesLauncher.java | 2 +- .../boot/loader/package-info.java | 2 +- 13 files changed, 45 insertions(+), 44 deletions(-) diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc index 52c59a7bd7..86c43c9344 100644 --- a/CONTRIBUTING.adoc +++ b/CONTRIBUTING.adoc @@ -130,7 +130,7 @@ With the requisite eclipse plugins installed you can select need to import the root `spring-boot` pom and the `spring-boot-samples` pom separately. === Importing into eclipse without m2eclipse -If you prefer not to use m2eclipse you can generate eclipse project meta-data using the +If you prefer not to use m2eclipse you can generate eclipse project metadata using the following command: [indent=0] diff --git a/spring-boot-actuator/README.adoc b/spring-boot-actuator/README.adoc index 9785931571..27cca445ea 100644 --- a/spring-boot-actuator/README.adoc +++ b/spring-boot-actuator/README.adoc @@ -47,5 +47,5 @@ For Gradle, use the declaration: authentication events by default. This can be very useful for reporting, and also to implement a lock-out policy based on authentication failures. * **Process Monitoring** In Spring Boot Actuator you can find `ApplicationPidListener` - which creates file containing application PID (by default in application directory and - file name is `application.pid`). + which creates a file containing the application PID (by default in the application + directory with a file name of `application.pid`). diff --git a/spring-boot-docs/src/main/asciidoc/appendix-application-properties.adoc b/spring-boot-docs/src/main/asciidoc/appendix-application-properties.adoc index 9acdee71ee..23a4f5f766 100644 --- a/spring-boot-docs/src/main/asciidoc/appendix-application-properties.adoc +++ b/spring-boot-docs/src/main/asciidoc/appendix-application-properties.adoc @@ -278,8 +278,8 @@ content into your application; rather pick only the properties that you need. spring.hornetq.embedded.serverId= # auto-generated id of the embedded server (integer) spring.hornetq.embedded.persistent=false # message persistence spring.hornetq.embedded.data-directory= # location of data content (when persistence is enabled) - spring.hornetq.embedded.queues= # comma separate queues to create on startup - spring.hornetq.embedded.topics= # comma separate topics to create on startup + spring.hornetq.embedded.queues= # comma-separated queues to create on startup + spring.hornetq.embedded.topics= # comma-separated topics to create on startup spring.hornetq.embedded.cluster-password= # customer password (randomly generated by default) # JMS ({sc-spring-boot-autoconfigure}/jms/JmsProperties.{sc-ext}[JmsProperties]) diff --git a/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc b/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc index e8210b36ed..3ded1579ed 100644 --- a/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc +++ b/spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc @@ -15,7 +15,7 @@ curious about the underlying technology, this section provides some background. === Nested JARs Java does not provide any standard way to load nested jar files (i.e. jar files that are themselves contained within a jar). This can be problematic if you are looking -to distribute a self contained application that you can just run from the command line +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 diff --git a/spring-boot-docs/src/main/asciidoc/build-tool-plugins.adoc b/spring-boot-docs/src/main/asciidoc/build-tool-plugins.adoc index f3fda5670a..d8a1685eeb 100644 --- a/spring-boot-docs/src/main/asciidoc/build-tool-plugins.adoc +++ b/spring-boot-docs/src/main/asciidoc/build-tool-plugins.adoc @@ -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 meta-data +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"] diff --git a/spring-boot-docs/src/main/asciidoc/cloud-deployment.adoc b/spring-boot-docs/src/main/asciidoc/cloud-deployment.adoc index 4d76c266b4..4b9bd59cd3 100644 --- a/spring-boot-docs/src/main/asciidoc/cloud-deployment.adoc +++ b/spring-boot-docs/src/main/asciidoc/cloud-deployment.adoc @@ -12,7 +12,7 @@ _cloud's_ notion of a running process. 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 +or it might be a full-fledged application server. A buildpack is pluggable, but ideally you should be able to get by with as few customizations to it as possible. This reduces the footprint of functionality that is not under your control. It minimizes divergence between deployment and production environments. @@ -103,7 +103,7 @@ able to hit the application at the URI given, in this case [[cloud-deployment-cloud-foundry-services]] === Binding to services -By default, meta-data about the running application as well as service connection +By default, metadata about the running application as well as service connection information is exposed to the application as environment variables (for example: `$VCAP_SERVICES`). This architecture decision is due to Cloud Foundry's polyglot (any language and platform can be supported as a buildpack) nature; process-scoped diff --git a/spring-boot-docs/src/main/asciidoc/howto.adoc b/spring-boot-docs/src/main/asciidoc/howto.adoc index 5909efc822..b29e18e50e 100644 --- a/spring-boot-docs/src/main/asciidoc/howto.adoc +++ b/spring-boot-docs/src/main/asciidoc/howto.adoc @@ -365,7 +365,7 @@ that and be sure that it has initialized is to add a `@Bean` of type `ApplicationListener` and pull the container out of the event when it is published. -A really useful thing to do in is to use `@IntegrationTest` to set `server.port=0` +A useful practice for use with `@IntegrationTest`s 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"] @@ -415,7 +415,7 @@ accessible on the filesystem, i.e. it cannot be read from within a jar file. Generally you can follow the advice from '<>' about `@ConfigurationProperties` (`ServerProperties` is the main one here), but also look at -`EmbeddedServletContainerCustomizer` and various Tomcat specific `+*Customizers+` that you +`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 `TomcatEmbeddedServletContainerFactory` you can modify it in a number of ways. Or the nuclear option is to add your own `TomcatEmbeddedServletContainerFactory`. @@ -423,9 +423,9 @@ nuclear option is to add your own `TomcatEmbeddedServletContainerFactory`. [[howto-enable-multiple-connectors-in-tomcat]] -=== Enable Multiple Connectors Tomcat +=== Enable Multiple Connectors with Tomcat Add a `org.apache.catalina.connector.Connector` to the -`TomcatEmbeddedServletContainerFactory` which can allow multiple connectors eg a HTTP and +`TomcatEmbeddedServletContainerFactory` which can allow multiple connectors, e.g. an HTTP and HTTPS connector: [source,java,indent=0,subs="verbatim,quotes,attributes"] @@ -855,7 +855,7 @@ then you can do that in `application.properties` using the "logging.level" prefi You can also set the location of a file to log to (in addition to the console) using "logging.file". -To configure the more fine grained settings of a logging system you need to use the native +To configure the more fine-grained settings of a logging system you need to use the native configuration format supported by the `LoggingSystem` in question. By default Spring Boot picks up the native configuration from its default location for the system (e.g. `classpath:logback.xml` for Logback), but you can set the location of the config file @@ -917,10 +917,10 @@ requires some jiggling with excludes, e.g. in Maven: org.springframework.boot spring-boot-starter - - org.springframework.boot - spring-boot-starter-logging - + + org.springframework.boot + spring-boot-starter-logging + @@ -930,7 +930,7 @@ requires some jiggling with excludes, e.g. in Maven: ---- NOTE: The use of the log4j starter gathers together the dependencies for common logging -requirements (e.g. including having Tomcat use `java.util.logging` but configure the +requirements (e.g. including having Tomcat use `java.util.logging` but configuring the output using Log4j). See the Actuator Log4j Sample for more detail and to see it in action. @@ -1246,7 +1246,7 @@ that can be used to disable the migrations, or switch off the location checking. By default Flyway will autowire the (`@Primary`) `DataSource` in your context and use that for migrations. If you like to use a different `DataSource` you can create one and mark its `@Bean` as `@FlywayDataSource` - if you do that remember to create -another one and mark it as `@Primary` if you want 2 data sources. +another one and mark it as `@Primary` if you want two data sources. Or you can use Flyway's native `DataSource` by setting `flyway.[url,user,password]` in external properties. @@ -1283,7 +1283,7 @@ Spring Batch auto configuration is enabled by adding `@EnableBatchProcessing` By default it executes *all* `Jobs` in the application context on startup (see {sc-spring-boot-autoconfigure}/batch/JobLauncherCommandLineRunner.{sc-ext}[JobLauncherCommandLineRunner] for details). You can narrow down to a specific job or jobs by specifying -`spring.batch.job.names` (comma separated job name patterns). +`spring.batch.job.names` (comma-separated job name patterns). If the application context includes a `JobRegistry` then the jobs in `spring.batch.job.names` are looked up in the registry instead of being autowired from the @@ -1527,7 +1527,7 @@ To configure IntelliJ correctly you can use the `idea` Gradle plugin: ---- -NOTE: Intellij must be configured to use the same Java version as the command line Gradle +NOTE: IntelliJ must be configured to use the same Java version as the command line Gradle task and `springloaded` *must* be included as a `buildscript` dependency. You can also additionally enable '`Make Project Automatically`' inside Intellij to @@ -1556,7 +1556,7 @@ you would add the following: ---- -NOTE: this only works if your Maven project inherits (directly or indirectly) from +NOTE: This only works if your Maven project inherits (directly or indirectly) from `spring-boot-dependencies`. If you have added `spring-boot-dependencies` in your own `dependencyManagement` section with `import` you have to redefine the artifact yourself instead of overriding the property . diff --git a/spring-boot-docs/src/main/asciidoc/production-ready-features.adoc b/spring-boot-docs/src/main/asciidoc/production-ready-features.adoc index b805c1e3fd..a8cc9c08be 100644 --- a/spring-boot-docs/src/main/asciidoc/production-ready-features.adoc +++ b/spring-boot-docs/src/main/asciidoc/production-ready-features.adoc @@ -605,7 +605,7 @@ from your command: [[production-ready-remote-shell-plugins]] ==== Remote shell plugins In addition to new commands, it is also possible to extend other CRaSH shell features. -All Spring Beans that extends `org.crsh.plugin.CRaSHPlugin` will be automatically +All Spring Beans that extend `org.crsh.plugin.CRaSHPlugin` will be automatically registered with the shell. For more information please refer to the http://www.crashub.org/[CRaSH reference @@ -832,8 +832,8 @@ In `META-INF/spring.factories` file you have to activate the listener: [[production-ready-process-monitoring-programmatically]] === Programmatically You can also activate this listener by invoking `SpringApplication.addListeners(...)` -method and passing `ApplicationPidListener` object. You can also customize file name -and path through constructor. +method and passing `ApplicationPidListener` object. You can also customize the file +name and path through its constructor. @@ -845,5 +845,5 @@ might want to read about graphing tools such as http://graphite.wikidot.com/[Gra Otherwise, you can continue on, to read about <> or jump ahead -for some in depth information about Spring Boot's +for some in-depth information about Spring Boot's '<>'. diff --git a/spring-boot-docs/src/main/asciidoc/spring-boot-cli.adoc b/spring-boot-docs/src/main/asciidoc/spring-boot-cli.adoc index e4241c4df2..1e33dd7708 100644 --- a/spring-boot-docs/src/main/asciidoc/spring-boot-cli.adoc +++ b/spring-boot-docs/src/main/asciidoc/spring-boot-cli.adoc @@ -76,7 +76,7 @@ using. [[cli-run]] === Running applications using the CLI 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. +is completely self-contained so you don't need any external Groovy installation. Here is an example ``hello world'' web application written in Groovy: @@ -272,7 +272,7 @@ executable jar file. For example: The resulting jar will contain the classes produced by compiling the application and all 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 +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 the defaults). The default includes are diff --git a/spring-boot-docs/src/main/asciidoc/spring-boot-features.adoc b/spring-boot-docs/src/main/asciidoc/spring-boot-features.adoc index bc4aea700d..ef4dbc8f93 100644 --- a/spring-boot-docs/src/main/asciidoc/spring-boot-features.adoc +++ b/spring-boot-docs/src/main/asciidoc/spring-boot-features.adoc @@ -1028,7 +1028,6 @@ behaviour by setting `com.ibm.ws.webcontainer.invokeFlushAfterService` to `false - [[boot-features-embedded-container]] === Embedded servlet container support Spring Boot includes support for embedded Tomcat and Jetty servers. Most developers will @@ -1044,7 +1043,7 @@ Spring beans. This can be particularly convenient if you want to refer to a valu your `application.properties` during configuration. By default, if the context contains only a single Servlet it will be mapped to `/`. In -the case of multiple Servlets beans the bean name will be used as a path prefix. Filters +the case of multiple Servlet beans the bean name will be used as a path prefix. Filters will map to `+/*+`. If convention-based mapping is not flexible enough you can use the @@ -1272,7 +1271,7 @@ auto-configured. In this example it's pulled in transitively via [[boot-features-connect-to-production-database]] ==== Connection to a production database Production database connections can also be auto-configured using a pooling -`DataSource`. Here's the algorithm for choosing a specific implementation. +`DataSource`. Here's the algorithm for choosing a specific implementation: * We prefer the Tomcat pooling `DataSource` for its performance and concurrency, so if that is available we always choose it. @@ -1304,6 +1303,8 @@ NOTE: For a pooling `DataSource` to be created we need to be able to verify that `spring.datasource.driverClassName=com.mysql.jdbc.Driver` then that class has to be loadable. + + [[boot-features-using-jdbc-template]] === Using JdbcTemplate Spring's `JdbcTemplate` and `NamedParameterJdbcTemplate` classes are auto-configured and @@ -1450,7 +1451,7 @@ their http://projects.spring.io/spring-data-jpa/[reference documentation]. [[boot-features-creating-and-dropping-jpa-databases]] ==== Creating and dropping JPA databases -By default JPA database will be automatically created *only* if you use an embedded +By default, JPA databases will be automatically created *only* if you use an embedded database (H2, HSQL or Derby). You can explicitly configure JPA settings using `+spring.jpa.*+` properties. For example, to create and drop tables you can add the following to your `application.properties`. @@ -1475,7 +1476,7 @@ passes `hibernate.globally_quoted_identifiers` to the Hibernate entity manager. By default the DDL execution (or validation) is deferred until the `ApplicationContext` has started. There is also a `spring.jpa.generate-ddl` flag, but it is not used if Hibernate autoconfig is active because the `ddl-auto` -settings are more fine grained. +settings are more fine-grained. @@ -1809,7 +1810,7 @@ connect to a broker using the the `netty` transport protocol. When the latter is configured, Spring Boot configures a `ConnectionFactory` connecting to a broker running on the local machine with the default settings. -NOTE: if you are using `spring-boot-starter-hornetq` the necessary dependencies to +NOTE: If you are using `spring-boot-starter-hornetq` the necessary dependencies to connect to an existing HornetQ instance are provided, as well as the Spring infrastructure to integrate with JMS. Adding `org.hornetq:hornetq-jms-server` to your application allows you to use the embedded mode. @@ -1826,7 +1827,7 @@ HornetQ configuration is controlled by external configuration properties in ---- When embedding the broker, you can chose if you want to enable persistence, and the list -of destinations that should be made available. These can be specified as a comma separated +of destinations that should be made available. These can be specified as a comma-separated list to create them with the default options; or you can define bean(s) of type `org.hornetq.jms.server.config.JMSQueueConfiguration` or `org.hornetq.jms.server.config.TopicConfiguration`, for advanced queue and topic @@ -1933,7 +1934,7 @@ If you use the the following provided libraries: * Spring Test -- integration test support for Spring applications. -* Junit -- The de-facto standard for unit testing Java applications. +* JUnit -- The de-facto standard for unit testing Java applications. * Hamcrest -- A library of matcher objects (also known as constraints or predicates) allowing `assertThat` style JUnit assertions. * Mockito -- A Java mocking framework. @@ -2001,7 +2002,7 @@ it with HTTP (e.g. using `RestTemplate`), annotate your test class (or one of it superclasses) with `@IntegrationTest`. This can be very useful because it means you can test the full stack of your application, but also inject its components into the test class and use them to assert the internal state of the application after an HTTP -interaction. For Example: +interaction. For example: [source,java,indent=0,subs="verbatim,quotes,attributes"] ---- @@ -2206,7 +2207,7 @@ You can use the {sc-spring-boot-autoconfigure}/AutoConfigureAfter.{sc-ext}[`@AutoConfigureAfter`] or {sc-spring-boot-autoconfigure}/AutoConfigureBefore.{sc-ext}[`@AutoConfigureBefore`] annotations if your configuration needs to be applied in a specific order. For example, -if you provide web specific configuration, your class may need to be applied after +if you provide web-specific configuration, your class may need to be applied after `WebMvcAutoConfiguration`. @@ -2227,7 +2228,7 @@ code by annotating `@Configuration` classes or individual `@Bean` methods. ==== Class conditions The `@ConditionalOnClass` and `@ConditionalOnMissingClass` annotations allows configuration to be skipped based on the presence or absence of specific classes. Due to the fact that -annotation meta-data is parsed using http://asm.ow2.org/[ASM] you can actually use the +annotation metadata is parsed using http://asm.ow2.org/[ASM] you can actually use the `value` attribute to refer to the real class, even though that class might not actually appear on the running application classpath. You can also use the `name` attribute if you prefer to specify the class name using a `String` value. diff --git a/spring-boot-docs/src/main/asciidoc/using-spring-boot.adoc b/spring-boot-docs/src/main/asciidoc/using-spring-boot.adoc index 54772d82e6..b18bbed5d6 100644 --- a/spring-boot-docs/src/main/asciidoc/using-spring-boot.adoc +++ b/spring-boot-docs/src/main/asciidoc/using-spring-boot.adoc @@ -549,7 +549,7 @@ and build system. Most IDEs can import Maven projects directly, for example Ecli can select `Import...` -> `Existing Maven Projects` from the `File` menu. If you can't directly import your project into your IDE, you may be able to generate IDE -meta-data using a build plugin. Maven includes plugins for +metadata using a build plugin. Maven includes plugins for 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]. @@ -638,7 +638,7 @@ See the <> section for de [[using-boot-packaging-for-production]] == Packaging your application for production -Executable jars can be used for production deployment. As they are self contained, they +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 diff --git a/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/PropertiesLauncher.java b/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/PropertiesLauncher.java index 12044c4c0f..6f8d6eeeb7 100644 --- a/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/PropertiesLauncher.java +++ b/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/PropertiesLauncher.java @@ -86,7 +86,7 @@ public class PropertiesLauncher extends Launcher { /** * Properties key for classpath entries (directories possibly containing jars). * Defaults to "lib/" (relative to {@link #HOME loader home directory}). Multiple - * entries can be specified using a comma separeted list. + * entries can be specified using a comma-separated list. */ public static final String PATH = "loader.path"; diff --git a/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/package-info.java b/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/package-info.java index 100cfb08dc..785f8af21b 100644 --- a/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/package-info.java +++ b/spring-boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/package-info.java @@ -15,7 +15,7 @@ */ /** - * System that allows self contained JAR/WAR archives to be launched using + * System that allows self-contained JAR/WAR archives to be launched using * {@code java -jar}. Archives can include nested packaged dependency JARs (there is * no need to create shade style jars) and are executed without unpacking. The only * constraint is that nested JARs must be stored in the archive uncompressed.