updated docs wording, typos, switching passive to active, etc. PR 4 of 4

src/main/docs/guide/ioc/scopes/builtInScopes.adoc

@@ -3,9 +3,9 @@
 |Type |Description
 
 |link:{jeeapi}/javax/inject/Singleton.html[@Singleton]
-|Singleton scope indicates only one instance of the bean should exist
+|Singleton scope indicates only one instance of the bean will exist
 |link:{api}/io/micronaut/context/annotation/Context.html[@Context]
-|Context scope indicates that the bean should be created at the same time as the `ApplicationContext` (eager initialization)
+|Context scope indicates that the bean will be created at the same time as the `ApplicationContext` (eager initialization)
 |link:{api}/io/micronaut/context/annotation/Prototype.html[@Prototype]
 |Prototype scope indicates that a new instance of the bean is created each time it is injected
 |link:{api}/io/micronaut/context/annotation/Infrastructure.html[@Infrastructure]
@@ -22,10 +22,10 @@ NOTE: The link:{api}/io/micronaut/context/annotation/Prototype.html[@Prototype]
 
 Additional scopes can be added by defining a `@Singleton` bean that implements the link:{api}/io/micronaut/context/scope/CustomScope.html[CustomScope] interface.
 
-Note that with Micronaut when starting an api:context.ApplicationContext[] by default `@Singleton` scoped beans are created lazily and on demand. This is by design and to optimize startup time.
+Note that when starting an api:context.ApplicationContext[], by default `@Singleton`-scoped beans are created lazily and on-demand. This is by design to optimize startup time.
 
 If this presents a problem for your use case you have the option of using the ann:context.annotation.Context[] annotation which binds the lifecycle of your object to the lifecycle of the api:context.ApplicationContext[]. In other words when the api:context.ApplicationContext[] is started your bean will be created.
 
-Alternatively you can annotate any `@Singleton` scoped bean with ann:context.annotation.Parallel[] which allows parallel initialization of your bean without impacting overall startup time.
+Alternatively, annotate any `@Singleton`-scoped bean with ann:context.annotation.Parallel[] which allows parallel initialization of your bean without impacting overall startup time.
 
-NOTE: If your bean fails to initialize in parallel then the application will be automatically shutdown.
+NOTE: If your bean fails to initialize in parallel, the application will be automatically shut down.

src/main/docs/guide/ioc/scopes/builtInScopes/eagerInit.adoc

@@ -1,6 +1,6 @@
 Eager initialization of `@Singleton` beans maybe desirable in certain scenarios, such as on AWS Lambda where more CPU resources are assigned to Lambda construction than execution.
 
-You can specify whether you want to initialize eagerly `@Singleton` scoped beans using the link:{api}/io/micronaut/context/ApplicationContextBuilder.html[ApplicationContextBuilder] interface:
+You can specify whether to eagerly initialize `@Singleton`-scoped beans using the link:{api}/io/micronaut/context/ApplicationContextBuilder.html[ApplicationContextBuilder] interface:
 
 .Enabling Eager Initialization of Singletons
 [source,java]
@@ -16,9 +16,9 @@ public class Application {
 }
 ----
 
-<1> Setting eager init to true initializes all singletons
+<1> Setting eager init to `true` initializes all singletons
 
-When you use Micronaut in environments such as <<serverlessFunctions, Serverless Functions>>, you will not have an Application class and instead you extend a Micronaut provided class. In those cases, Micronaut provides methods which you can override to enhance the api:context.ApplicationContextBuilder[]
+When you use Micronaut in environments such as <<serverlessFunctions, Serverless Functions>>, you will not have an Application class and instead you extend a Micronaut-provided class. In those cases, Micronaut provides methods which you can override to enhance the api:context.ApplicationContextBuilder[]
 
 .Override of newApplicationContextBuilder()
 [source,java]
@@ -36,7 +36,7 @@ public class MyFunctionHandler extends MicronautRequestHandler<APIGatewayProxyRe
 }
 ----
 
-ann:context.annotation.ConfigurationReader[] beans such as ann:context.annotation.EachProperty[]  or ann:context.annotation.ConfigurationProperties[] are singleton beans. If you want to eager init configuration, but keep other `@Singleton` scoped beans creation lazy, use `eagerInitConfiguration`:
+ann:context.annotation.ConfigurationReader[] beans such as ann:context.annotation.EachProperty[]  or ann:context.annotation.ConfigurationProperties[] are singleton beans. To eagerly init configuration but keep other `@Singleton`-scoped bean creation lazy, use `eagerInitConfiguration`:
 
 .Enabling Eager Initialization of Configuration
 [source,java]
@@ -53,4 +53,3 @@ public class Application {
 ----
 
 <1> Setting eager init to true initializes all configuration reader beans.
-

src/main/docs/guide/ioc/scopes/metaScopes.adoc

@@ -1,4 +1,4 @@
-Scopes can be defined on Meta annotations that you can then apply to your classes. Consider the following example meta annotation:
+Scopes can be defined on meta annotations that you can then apply to your classes. Consider the following example meta annotation:
 
 .Driver.java Annotation
 
@@ -20,14 +20,13 @@ class Foo {}
 ----
 // TODO should this be converted? it would be the same in every language I think
 
-If you wish for the scope to be overridable you should instead use the api:context.annotation.DefaultScope[] annotation on `@Driver` which allows a default scope to be specified if none other is present:
+For the scope to be overridable, instead use the api:context.annotation.DefaultScope[] annotation on `@Driver` which allows a default scope to be specified if none other is present:
 
 .Using @DefaultScope
 
-
 [source.multi-language-sample,java]
 ----
-@Requires(classes = Car.class )
+@Requires(classes = Car.class)
 @DefaultScope(Singleton.class) // <1>
 @Documented
 @Retention(RUNTIME)
@@ -36,7 +35,7 @@ public @interface Driver {
 ----
 [source.multi-language-sample,groovy]
 ----
-@Requires(classes = Car.class )
+@Requires(classes = Car.class)
 @DefaultScope(Singleton.class) // <1>
 @Documented
 @Retention(RUNTIME)
@@ -52,4 +51,4 @@ public @interface Driver {
 annotation class Driver
 ----
 
-<1> api:context.annotation.DefaultScope[] is used to declare which scope to be used if none is present
+<1> api:context.annotation.DefaultScope[] declares the scope to use if none is specified

src/main/docs/guide/ioc/scopes/refreshable.adoc

@@ -3,16 +3,15 @@ The api:runtime.context.scope.Refreshable[] scope is a custom scope that allows
 - `/refresh` endpoint.
 - Publication of a api:runtime.context.scope.refresh.RefreshEvent[].
 
-The following example, illustrates the `@Refreshable` scope behavior.
+The following example illustrates `@Refreshable` scope behavior.
 
 snippet::io.micronaut.docs.inject.scope.RefreshEventSpec[tags="weatherService",indent="0"]
 
-
 <1> The `WeatherService` is annotated with `@Refreshable` scope which stores an instance until a refresh event is triggered
 <2> The value of the `forecast` property is set to a fixed value when the bean is created and won't change until the bean is refreshed
 
-If you invoke the `latestForecast()` twice, you will see identical responses such as `"Scattered Clouds 01/Feb/18 10:29.199"`.
+If you invoke `latestForecast()` twice, you will see identical responses such as `"Scattered Clouds 01/Feb/18 10:29.199"`.
 
-When the `/refresh` endpoint is invoked or a api:runtime.context.scope.refresh.RefreshEvent[] is published then the instance is invalidated and a new instance is created the next time the object is requested. For example:
+When the `/refresh` endpoint is invoked or a api:runtime.context.scope.refresh.RefreshEvent[] is published, the instance is invalidated and a new instance is created the next time the object is requested. For example:
 
-snippet::io.micronaut.docs.inject.scope.RefreshEventSpec[tags="publishEvent",indent="0"]
+snippet::io.micronaut.docs.inject.scope.RefreshEventSpec[tags="publishEvent",indent="0"]

src/main/docs/guide/languageSupport/graal.adoc

@@ -1,18 +1,13 @@
-https://www.graalvm.org[GraalVM] is a new universal virtual machine from Oracle that supports a polyglot runtime environment and the ability to compile Java applications down to native machine code.
+https://www.graalvm.org[GraalVM] is a new universal virtual machine from Oracle that supports a polyglot runtime environment and the ability to compile Java applications to native machine code.
 
 Any Micronaut application can be run using the GraalVM JVM, however special support has been added to Micronaut to support running Micronaut applications using https://www.graalvm.org/docs/reference-manual/aot-compilation/[GraalVM's `native-image` tool].
 
-Micronaut currently supports GraalVM {graalVersion} version and the team is improving the support in every new release. Don't
-hesitate to https://github.com/micronaut-projects/micronaut-core/issues[report issues] however if you find any problem.
+Micronaut currently supports GraalVM version {graalVersion} and the team is improving the support in every new release. Don't hesitate to https://github.com/micronaut-projects/micronaut-core/issues[report issues] however if you find any problem.
 
-A lot of Micronaut's modules and third party libraries have been verified to work with GraalVM: HTTP server, HTTP client,
-Function support, Micronaut Data JDBC and JPA, Service Discovery, RabbitMQ, Views, Security, Zipkin,... Support for other
-modules is still evolving and will improve over time.
+Many of Micronaut's modules and third-party libraries have been verified to work with GraalVM: HTTP server, HTTP client, Function support, Micronaut Data JDBC and JPA, Service Discovery, RabbitMQ, Views, Security, Zipkin, etc. Support for other modules is evolving and will improve over time.
 
 === Getting Started
 
-NOTE: Use of GraalVM's `native-image` tool is only supported in Java or Kotlin projects. Groovy relies heavily on
-reflection which is only partially supported by GraalVM.
+NOTE: Use of GraalVM's `native-image` tool is only supported in Java or Kotlin projects. Groovy relies heavily on reflection which is only partially supported by GraalVM.
 
-To start using GraalVM you should first install the GraalVM SDK via the https://www.graalvm.org/docs/getting-started/[Getting Started]
-or using https://sdkman.io/[Sdkman!].
+To start using GraalVM, first install the GraalVM SDK via the https://www.graalvm.org/docs/getting-started/[Getting Started]  instructions or using https://sdkman.io/[Sdkman!].

src/main/docs/guide/languageSupport/graal/graalFAQ.adoc

@@ -6,7 +6,6 @@ Micronaut features a Dependency Injection and Aspect-Oriented Programming runtim
 
 Picocli provides a `picocli-codegen` module with a tool for generating a GraalVM reflection configuration file. The tool can be run https://picocli.info/picocli-on-graalvm.html[manually] or automatically as part of the build. The module's https://github.com/remkop/picocli/tree/master/picocli-codegen[README] has usage instructions with code snippets for configuring Gradle and Maven to generate a `cli-reflect.json` file automatically as part of the build. Add the generated file to the `-H:ReflectionConfigurationFiles` option when running the `native-image` tool.
 
-
 ==== What about other Third-Party Libraries?
 
 Micronaut cannot guarantee that third-party libraries work on GraalVM SubstrateVM, that is down to each individual library to implement support.
@@ -32,7 +31,7 @@ You may need to manually tweak the generated `reflect.json` file. For regular cl
 ]
 ----
 
-For arrays this needs to use the Java JVM internal array representation. For example:
+For arrays this must use the Java JVM internal array representation. For example:
 
 [source,json]
 ----
@@ -47,17 +46,17 @@ For arrays this needs to use the Java JVM internal array representation. For exa
 
 ==== What if I want to set the heap's maximum size with `-Xmx`, but I get an `OutOfMemoryError`?
 
-If you set heap's maximum size in the Dockerfile that you use to build your native image, you will probably get runtime an error like this:
+If you set the maximum heap size in the Dockerfile that you use to build your native image, you will probably get a runtime error like this:
 
 ----
 java.lang.OutOfMemoryError: Direct buffer memory
 ----
 
-The problem is that Netty is trying to allocate 16MiB of memory per chunk with its default settings for `io.netty.allocator.pageSize` and `io.netty.allocator.maxOrder`:
+The problem is that Netty tries to allocate 16MB of memory per chunk with its default settings for `io.netty.allocator.pageSize` and `io.netty.allocator.maxOrder`:
 
 [source, java]
 ----
-int defaultChunkSize = DEFAULT_PAGE_SIZE << DEFAULT_MAX_ORDER; // 8192 << 11 = 16MiB 
+int defaultChunkSize = DEFAULT_PAGE_SIZE << DEFAULT_MAX_ORDER; // 8192 << 11 = 16MB
 ----
 
 The simplest solution is to specify `io.netty.allocator.maxOrder` explicitly in your Dockerfile's entrypoint. A working example with `-Xmx64m`:
@@ -67,4 +66,4 @@ The simplest solution is to specify `io.netty.allocator.maxOrder` explicitly in
 ENTRYPOINT ["/app/application", "-Xmx64m", "-Dio.netty.allocator.maxOrder=8"]
 ----
 
-If you want to go further, you can also experiment with `io.netty.allocator.numHeapArenas` or `io.netty.allocator.numDirectArenas`. You can find more information about Netty's `PooledByteBufAllocator` in the https://netty.io/4.1/api/io/netty/buffer/PooledByteBufAllocator.html[official documentation].
+To go further, you can also experiment with `io.netty.allocator.numHeapArenas` or `io.netty.allocator.numDirectArenas`. You can find more information about Netty's `PooledByteBufAllocator` in the https://netty.io/4.1/api/io/netty/buffer/PooledByteBufAllocator.html[official documentation].