diff --git a/src/main/docs/guide/ioc/scopes/builtInScopes.adoc b/src/main/docs/guide/ioc/scopes/builtInScopes.adoc index caab099700e..a2ef4221310 100644 --- a/src/main/docs/guide/ioc/scopes/builtInScopes.adoc +++ b/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. diff --git a/src/main/docs/guide/ioc/scopes/builtInScopes/eagerInit.adoc b/src/main/docs/guide/ioc/scopes/builtInScopes/eagerInit.adoc index 2623346633a..564eb35dad2 100644 --- a/src/main/docs/guide/ioc/scopes/builtInScopes/eagerInit.adoc +++ b/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 <>, 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 <>, 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 Setting eager init to true initializes all configuration reader beans. - diff --git a/src/main/docs/guide/ioc/scopes/metaScopes.adoc b/src/main/docs/guide/ioc/scopes/metaScopes.adoc index 67059bdb876..4e099f51df2 100644 --- a/src/main/docs/guide/ioc/scopes/metaScopes.adoc +++ b/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 diff --git a/src/main/docs/guide/ioc/scopes/refreshable.adoc b/src/main/docs/guide/ioc/scopes/refreshable.adoc index c857134d853..5c4d18316d6 100644 --- a/src/main/docs/guide/ioc/scopes/refreshable.adoc +++ b/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"] \ No newline at end of file +snippet::io.micronaut.docs.inject.scope.RefreshEventSpec[tags="publishEvent",indent="0"] diff --git a/src/main/docs/guide/languageSupport/graal.adoc b/src/main/docs/guide/languageSupport/graal.adoc index abc6feae45d..3fb135dbce3 100644 --- a/src/main/docs/guide/languageSupport/graal.adoc +++ b/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!]. diff --git a/src/main/docs/guide/languageSupport/graal/graalFAQ.adoc b/src/main/docs/guide/languageSupport/graal/graalFAQ.adoc index 36a0b96842c..cfceaf5626a 100644 --- a/src/main/docs/guide/languageSupport/graal/graalFAQ.adoc +++ b/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]. diff --git a/src/main/docs/guide/languageSupport/graal/graalServices.adoc b/src/main/docs/guide/languageSupport/graal/graalServices.adoc index 4603c3ee9e2..c89ea97f191 100644 --- a/src/main/docs/guide/languageSupport/graal/graalServices.adoc +++ b/src/main/docs/guide/languageSupport/graal/graalServices.adoc @@ -1,8 +1,8 @@ -=== Getting Started with Micronaut and Graal +=== Getting Started with Micronaut and GraalVM -Since Micronaut 2.2, any Micronaut application is already ready to be built into a native image using the Micronaut Gradle or Maven plugins, to get started simply create a new application: +Since Micronaut 2.2, any Micronaut application is ready to be built into a native image using the Micronaut Gradle or Maven plugins. To get started, create a new application: -.Creating a Graal Native Microservice +.Creating a GraalVM Native Microservice [source,bash] ---- $ mn create-app hello-world @@ -12,7 +12,7 @@ You can use `--build maven` for a Maven build. ==== Building a Native Image Using Docker -To build your native image using Gradle and Docker simply run: +To build your native image using Gradle and Docker, run: .Building a Native Image with Docker and Gradle [source,bash] @@ -20,7 +20,7 @@ To build your native image using Gradle and Docker simply run: $ ./gradlew dockerBuildNative ---- -To build your native image using Maven and Docker simply run: +To build your native image using Maven and Docker, run: .Building a Native Image with Docker and Maven [source,bash] @@ -30,16 +30,16 @@ $ ./mvnw package -Dpackaging=docker-native ==== Building a Native Image Without Using Docker -To build your native image without using Docker you need to install GraalVM SDK via the https://www.graalvm.org/docs/getting-started/[Getting Started] instructions or using https://sdkman.io/[Sdkman!]: +To build your native image without using Docker, install the GraalVM SDK via the https://www.graalvm.org/docs/getting-started/[Getting Started] instructions or using https://sdkman.io/[Sdkman!]: .Installing GraalVM {graalVersion} with SDKman [source,bash,subs="attributes+"] ---- -$ sdk install java {graalVersion}.r8-grl # or {graalVersion}.r11-grl if you want to use JDK 11 +$ sdk install java {graalVersion}.r8-grl # or {graalVersion}.r11-grl to use JDK 11 $ sdk use java {graalVersion}.r8-grl ---- -The `native-image` tool was extracted from the base GraalVM distribution. Currently, it is available as an early adopter plugin. To install it, run: +The `native-image` tool was extracted from the base GraalVM distribution and is available as a plugin. To install it, run: .Installing `native-image` tool [source,bash] @@ -47,7 +47,7 @@ The `native-image` tool was extracted from the base GraalVM distribution. Curren $ gu install native-image ---- -Now you can build a native image with Gradle simply by running the `nativeImage` task: +Now you can build a native image with Gradle by running the `nativeImage` task: .Creating native image with Gradle [source,bash] @@ -55,9 +55,9 @@ Now you can build a native image with Gradle simply by running the `nativeImage` $ ./gradlew nativeImage ---- -The native image will be built to the `build/native-image` directory. +The native image will be built in the `build/native-image` directory. -To create a native image with Maven and the Micronaut Maven plugin use `native-image` as the packaging format: +To create a native image with Maven and the Micronaut Maven plugin, use the `native-image` packaging format: .Creating native image with Maven [source,bash] @@ -65,9 +65,9 @@ To create a native image with Maven and the Micronaut Maven plugin use `native-i $ ./mvnw package -Dpackaging=native-image ---- -Which will build the native image into the `target` directory. +which builds the native image in the `target` directory. -You can then run the native image from the directory you built it to. +You can then run the native image from the directory where you built it. .Run native image [source,bash] @@ -75,21 +75,19 @@ You can then run the native image from the directory you built it to. $ ./hello-world ---- -=== Understanding Micronaut and Graal +=== Understanding Micronaut and GraalVM -Micronaut itself does not rely on reflection or dynamic classloading so works automatically with GraalVM native, however certain third party libraries used by Micronaut may require additional input about uses of reflection. +Micronaut itself does not rely on reflection or dynamic classloading, so it works automatically with GraalVM native, however certain third-party libraries used by Micronaut may require additional input about uses of reflection. -Micronaut includes an annotation processor that helps to handle generating the `reflect-config.json` and `resource-config.json` -metadata files that are automatically picked up by the `native-image` tool: +Micronaut includes an annotation processor that helps to generate the `reflect-config.json` and `resource-config.json` metadata files that are automatically picked up by the `native-image` tool: dependency:micronaut-graal[scope="annotationProcessor"] -This processor will generate: +This processor generates: - A `reflect-config.json` file in the `META-INF/native-image` directory in your build classes directory (`target/classes` with Maven and typically `build/classes/java/main` with Gradle). - A `native-image.properties` file to read this configuration for all classes annotated with either ann:core.annotation.Introspected[] or ann:core.annotation.TypeHint[]. -- A `resource-config.json` file also in the `META-INF/native-image` directory in your build classes directory containing -all the files in the `src/main/resources` file. +- A `resource-config.json` file also in the `META-INF/native-image` directory in your build classes directory containing information about the files in the `src/main/resources` directory. For example the following class: @@ -105,21 +103,19 @@ class Test { } ---- -The above example will result in the public methods and declared constructors of `example.Test` being included in `reflect-config.json`. +The above example results in the public methods and declared constructors of `example.Test` being included in `reflect-config.json`. -If you have more advanced requirements and only wish to include certain fields or methods, you can use ann:core.annotation.ReflectiveAccess[] instead which can be present on any constructor, field or method to include only the specific field, constructor or method. +If you have more advanced requirements and only wish to include certain fields or methods, use ann:core.annotation.ReflectiveAccess[] instead which can be present on any constructor, field or method to include only the specific field, constructor or method. -TIP: If you wish to provide your own `reflect.json` you can add one to `src/main/graal/reflect.json` and it will be automatically picked up. +TIP: To provide your own `reflect.json`, add one to `src/main/graal/reflect.json` and it will be automatically picked up. -Stating with Micronaut 2.0, as the framework generates automatically the file `resource-config.json`, if you want to -include your own additional resources you can provide them in `src/main/graal/resource-config.json` and they will -automatically added to the generated file. +Stating with Micronaut 2.0, as the framework automatically generates the `resource-config.json` file, to include your own additional resources, provide them in `src/main/graal/resource-config.json` and they will automatically be added to the generated file. === Adding Additional Classes for Reflective Access -To inform Micronaut of additional classes that should be included in the generated `reflect.json` file at compilation time you can either annotate a class with ann:core.annotation.Introspected[] or ann:core.annotation.TypeHint[]. +To inform Micronaut of additional classes to be included in the generated `reflect.json` file at compile time, either annotate a class with ann:core.annotation.Introspected[] or ann:core.annotation.TypeHint[]. -The former will generate a compile time introspection as well as allowing reflective access and the latter will only allow reflective access and is typically used on a module or `Application` class to include classes that are needed reflectively. For example, the following is taken from Micronaut's Jackson module: +The former generates a compile-time introspection as well as allowing reflective access, and the latter only allows reflective access, and is typically used on a module or `Application` class to include classes that are needed reflectively. For example, the following is from Micronaut's Jackson module: [source,java] ---- @@ -134,21 +130,21 @@ The former will generate a compile time introspection as well as allowing reflec ) ---- -<1> The `value` member is used to specify which classes require reflection. +<1> The `value` member specifies which classes require reflection. <2> The `accessType` member specifies if only classloading access is needed or whether full reflection on all public members is needed. === Generating Native Images -GraalVM's `native-image` command is used to generate native images. You can use this command manually to generate your native image. An example can be seen below. +GraalVM's `native-image` command generates native images. You can use this command manually to generate your native image. For example: .The `native-image` command [source,bash] ---- native-image --class-path build/libs/hello-world-0.1-all.jar # <1> ---- -<1> The `class-path` argument is used to refer to the Micronaut shaded JAR +<1> The `class-path` argument refers to the Micronaut shaded JAR -Once the image has been built you can run the application using the native image name: +Once the image is built, run the application using the native image name: .Running the Native Application [source,bash] @@ -157,4 +153,4 @@ $ ./hello-world 15:15:15.153 [main] INFO io.micronaut.runtime.Micronaut - Startup completed in 14ms. Server Running: http://localhost:8080 ---- -As you can see the advantage of having a native image is startup completes in milliseconds and memory consumption does not include the overhead of the JVM (a native Micronaut application runs with just 20mb of memory). +As you can see, the native image startup completes in milliseconds, and memory consumption does not include the overhead of the JVM (a native Micronaut application runs with just 20mb of memory). diff --git a/src/main/docs/guide/languageSupport/groovy.adoc b/src/main/docs/guide/languageSupport/groovy.adoc index 584256dea0b..2a154f49a0a 100644 --- a/src/main/docs/guide/languageSupport/groovy.adoc +++ b/src/main/docs/guide/languageSupport/groovy.adoc @@ -1,10 +1,10 @@ -The http://groovy-lang.org[Groovy language] has first class support in Micronaut. +http://groovy-lang.org[Groovy] has first-class support in Micronaut. -== Groovy Specific Modules +== Groovy-Specific Modules Additional modules exist specific to Groovy that improve the overall experience. These are detailed in the table below: -.Groovy Specific Modules +.Groovy-Specific Modules |=== |Dependency|Description @@ -12,18 +12,18 @@ Additional modules exist specific to Groovy that improve the overall experience. |Includes AST transformations to generate bean definitions. Should be `compileOnly` on your classpath. |`io.micronaut:micronaut-runtime-groovy` -|Adds the ability to specify configuration placed in `src/main/resources` in Groovy format (i.e. `application.groovy`) +|Adds the ability to specify configuration under `src/main/resources` in Groovy format (i.e. `application.groovy`) |`io.micronaut:micronaut-function-groovy` |Includes AST transforms that make it easier to write <> for AWS Lambda |=== -The most common module you will need is `micronaut-inject-groovy`, which enables DI and AOP for classes written in Groovy. +The most common module you need is `micronaut-inject-groovy`, which enables DI and AOP for Groovy classes. == Groovy Support in the CLI -The <> for Micronaut includes special support for Groovy. To create a Groovy application use the `groovy` lang option. For example: +The Micronaut <> includes special support for Groovy. To create a Groovy application, use the `groovy` lang option. For example: [source,bash] .Create a Micronaut Groovy application @@ -31,9 +31,9 @@ The <> for Micronaut includes special support for G $ mn create-app hello-world --lang groovy ---- -The above will generate a Groovy project, built with Gradle. You can use the `-build maven` flag to generate a project built with Maven instead. +The above generates a Groovy project, built with Gradle. Use the `-build maven` flag to generate a project built with Maven instead. -Once you have created an application with the `groovy` feature commands like `create-controller`, `create-client` etc. will generate Groovy files instead of Java. The following example demonstrates this action when using interactive mode of the CLI: +Once you have created an application with the `groovy` feature, commands like `create-controller`, `create-client` etc. generate Groovy files instead of Java. The following example demonstrates this when using interactive mode of the CLI: [source,bash] .Create a bean @@ -123,7 +123,7 @@ class HelloController { } ---- -As you can see from the output from the CLI a http://spockframework.org[Spock] test was also generated for you demonstrating how to test the controller: +As you can see from the output from the CLI, a http://spockframework.org[Spock] test was also generated for you which demonstrates how to test the controller: [source,groovy] .HelloControllerSpec.groovy @@ -143,9 +143,9 @@ Notice how you use Micronaut both as client and as a server to test itself. == Programmatic Routes with GroovyRouterBuilder -If you prefer to build your routes programmatically (similar to Grails `UrlMappings`) then a special `io.micronaut.web.router.GroovyRouteBuilder` exists that has some enhancements to make the DSL better. +If you prefer to build your routes programmatically (similar to Grails `UrlMappings`), a special `io.micronaut.web.router.GroovyRouteBuilder` exists that has some enhancements to make the DSL better. -The following example shows `GroovyRouteBuilder` in act: +The following example shows `GroovyRouteBuilder` in action: .Using GroovyRouteBuilder [source,groovy] @@ -165,7 +165,7 @@ The above example results in the following routes: == Using GORM in a Groovy application -http://gorm.grails.org[GORM] is a data access toolkit originally created as part of Grails framework. It supports multiple database types. The following table summarizes the modules needed to use GORM and links to documentation. +http://gorm.grails.org[GORM] is a data access toolkit originally created as part of Grails. It supports multiple database types. The following table summarizes the modules needed to use GORM, and links to documentation. .GORM Modules |=== @@ -203,7 +203,7 @@ abstract class VehicleService { ---- -You can also define the service as an interface instead of an abstract class if you want GORM to do all of the work and you don't want to add your own behaviors. +You can also define the service as an interface instead of an abstract class to have GORM implement the methods for you. == Serverless Functions with Groovy diff --git a/src/main/docs/guide/languageSupport/java.adoc b/src/main/docs/guide/languageSupport/java.adoc index be40689a3e8..7f8c0c4d25a 100644 --- a/src/main/docs/guide/languageSupport/java.adoc +++ b/src/main/docs/guide/languageSupport/java.adoc @@ -1,3 +1,3 @@ For Java, Micronaut uses a Java api:annotation.processing.BeanDefinitionInjectProcessor[] annotation processor to process classes at compile time and produce api:inject.BeanDefinition[] classes. -The major advantage here is that you pay a slight cost at compile time, but at runtime Micronaut is largely reflection-free, fast and consumes very little memory. +The major advantage here is that you pay a slight cost at compile time, but at runtime Micronaut is largely reflection-free, fast, and consumes very little memory. diff --git a/src/main/docs/guide/languageSupport/java/ide.adoc b/src/main/docs/guide/languageSupport/java/ide.adoc index 94c60a57beb..bcc24819208 100644 --- a/src/main/docs/guide/languageSupport/java/ide.adoc +++ b/src/main/docs/guide/languageSupport/java/ide.adoc @@ -1,5 +1,5 @@ You can use any IDE to develop Micronaut applications, if you depend on your configured build tool (Gradle or Maven) to build the application. -However, if you wish to run tests within the IDE that is currently possible with http://jetbrains.com/idea[IntelliJ IDEA] or Eclipse 4.9 M2 or above. +However, running tests within the IDE is currently possible with http://jetbrains.com/idea[IntelliJ IDEA] or Eclipse 4.9 or higher. -See the section on <> in the Quick start for more information on how to configure IntelliJ or Eclipse. \ No newline at end of file +See the section on <> in the Quick start for more information on how to configure IntelliJ and Eclipse. diff --git a/src/main/docs/guide/languageSupport/java/incrementalannotationgradle.adoc b/src/main/docs/guide/languageSupport/java/incrementalannotationgradle.adoc index 87fd4bcd61d..bec3a2ecffc 100644 --- a/src/main/docs/guide/languageSupport/java/incrementalannotationgradle.adoc +++ b/src/main/docs/guide/languageSupport/java/incrementalannotationgradle.adoc @@ -1,4 +1,4 @@ -Micronaut supports https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing[Gradle incremental annotation processing] which helps speed up builds by compiling only classes that have changed avoiding a full recompilation. +Micronaut supports https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing[Gradle incremental annotation processing] which speeds up builds by compiling only classes that have changed, avoiding a full recompilation. However, the support is disabled by default since Micronaut allows the definition of custom meta-annotations (to for example define <>) that need to be configured for processing. @@ -15,4 +15,4 @@ tasks.withType(JavaCompile) { } ---- -WARNING: If you do not enable processing for custom annotations you define these annotations will simple be ignored by Micronaut which may break your application. \ No newline at end of file +WARNING: If you do not enable processing for your custom annotations, they will be ignored by Micronaut, which may break your application. diff --git a/src/main/docs/guide/languageSupport/java/java9.adoc b/src/main/docs/guide/languageSupport/java/java9.adoc index f87ef1d6a77..e81b6e6086e 100644 --- a/src/main/docs/guide/languageSupport/java/java9.adoc +++ b/src/main/docs/guide/languageSupport/java/java9.adoc @@ -1,18 +1,19 @@ -Micronaut is built with Java 8, however works fine with Java 9/10 and above as well. The classes that Micronaut generates sit alongside existing classes within the same package, hence do not violate anything regarding the Java module system. +Micronaut is built with Java 8 but works fine with Java 9 and above. The classes that Micronaut generates sit alongside existing classes in the same package, hence do not violate anything regarding the Java module system. -There are some considerations to take into account when using Java 9/10 with Micronaut. +There are some considerations when using Java 9+ with Micronaut. === The javax.annotation package + [TIP] .Using the CLI ==== -If you are creating your project using the Micronaut CLI, the `javax.annotation` dependency will be added to your project automatically if you are using Java 9+. +If you create your project using the Micronaut CLI, the `javax.annotation` dependency is added to your project automatically if you use Java 9+. ==== -The `javax.annotation`, which includes `@PostConstruct`, `@PreDestroy` etc. is no longer part of the core JDK but instead a module. If you run under Java 9+ you will need to import the module or add the dependency to your classpath: +The `javax.annotation`, which includes `@PostConstruct`, `@PreDestroy`, etc. has been moved from the core JDK to a module. If you run under Java 9+, import the module or add the dependency to your build: .Adding the `javax.annotation` dependency [source,groovy] ---- implementation 'javax.annotation:javax.annotation-api:1.3.2' ----- \ No newline at end of file +---- diff --git a/src/main/docs/guide/languageSupport/java/lombok.adoc b/src/main/docs/guide/languageSupport/java/lombok.adoc index 63216bd018b..af3f76c0376 100644 --- a/src/main/docs/guide/languageSupport/java/lombok.adoc +++ b/src/main/docs/guide/languageSupport/java/lombok.adoc @@ -1,8 +1,8 @@ https://projectlombok.org[Project Lombok] is a popular java library that adds a number of useful AST transformations to the Java language via annotation processors. -Since both Micronaut and Lombok use annotation processors, special care needs to be taken when configuring Lombok to ensure that the Lombok processor runs *before* Micronaut's processor. +Since both Micronaut and Lombok use annotation processors, special care must be taken when configuring Lombok to ensure that the Lombok processor runs *before* Micronaut's processor. -For example in Gradle adding the following dependencies to the `dependencies` block: +If you use Gradle, add the following dependencies: .Configuring Lombok in Gradle [source,groovy] @@ -10,11 +10,11 @@ For example in Gradle adding the following dependencies to the `dependencies` bl compileOnly 'org.projectlombok:lombok:1.18.12' annotationProcessor "org.projectlombok:lombok:1.18.12" ... -// Micronaut processor define after Lombok +// Micronaut processor defined after Lombok annotationProcessor "io.micronaut:micronaut-inject-java" ---- -Or when using Maven: +Or if using Maven: .Configuring Lombok in Maven [source,xml] @@ -48,4 +48,4 @@ Or when using Maven: ---- -NOTE: In both cases (Gradle and Maven) the Micronaut processor should be configured after the Lombok processor, reversing the order of the declared dependencies will not work. +NOTE: In both cases (Gradle and Maven) the Micronaut processor must be configured after the Lombok processor. Reversing the order of the declared dependencies will not work. diff --git a/src/main/docs/guide/languageSupport/java/retainparameternames.adoc b/src/main/docs/guide/languageSupport/java/retainparameternames.adoc index 34f359ddc27..942b06f0840 100644 --- a/src/main/docs/guide/languageSupport/java/retainparameternames.adoc +++ b/src/main/docs/guide/languageSupport/java/retainparameternames.adoc @@ -11,7 +11,7 @@ interface HelloOperations { } ---- -At compile time the parameter name `name` is lost and becomes simply `arg0` when compiled against or read via reflection later. To avoid this problem you have two options. You can either declare the parameter name explicitly: +At compile time the parameter name `name` is lost and becomes `arg0` when compiled against or read via reflection later. To avoid this problem you have two options. You can either declare the parameter name explicitly: .Client Interface [source,java] @@ -22,10 +22,10 @@ interface HelloOperations { } ---- -Or alternatively it is recommended that you compile all byte code with `-parameters` flag to `javac`. See https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html[Obtaining Names of Method Parameters]. For example in `build.gradle`: +Or alternatively it is recommended that you compile all bytecode with `-parameters` flag to `javac`. See https://docs.oracle.com/javase/tutorial/reflect/member/methodparameterreflection.html[Obtaining Names of Method Parameters]. For example in `build.gradle`: .build.gradle [source,groovy] ---- compileJava.options.compilerArgs += '-parameters' ----- \ No newline at end of file +---- diff --git a/src/main/docs/guide/languageSupport/kotlin.adoc b/src/main/docs/guide/languageSupport/kotlin.adoc index 8c900b22ff2..244f163c790 100644 --- a/src/main/docs/guide/languageSupport/kotlin.adoc +++ b/src/main/docs/guide/languageSupport/kotlin.adoc @@ -6,7 +6,7 @@ TIP: The <> for Micronaut includes special support $ mn create-app hello-world --lang kotlin ---- -Support for Kotlin in Micronaut is built upon the https://kotlinlang.org/docs/reference/kapt.html[Kapt] compiler plugin, which includes support for Java annotation processors. To use Kotlin in your Micronaut application, you will simply need to add the proper dependencies to configure and run kapt on your `kt` source files. Kapt will create Java "stub" classes for each of your Kotlin classes, which can then be processed by Micronaut's Java annotation processor. The stubs are not included in the final compiled application. +Support for Kotlin in Micronaut is built upon the https://kotlinlang.org/docs/reference/kapt.html[Kapt] compiler plugin, which includes support for Java annotation processors. To use Kotlin in your Micronaut application, add the proper dependencies to configure and run kapt on your `kt` source files. Kapt creates Java "stub" classes for your Kotlin classes, which can then be processed by Micronaut's Java annotation processor. The stubs are not included in the final compiled application. TIP: Learn more about kapt and its features from the https://kotlinlang.org/docs/reference/kapt.html[official documentation.] @@ -25,7 +25,6 @@ dependencies { } ---- - <1> Add the Kotlin standard libraries <2> Add the `micronaut-inject-java` dependency under the `kapt` scope, so classes in `src/main` are processed <3> Add the `micronaut-inject-java` dependency under the `kaptTest` scope, so classes in `src/test` are processed. @@ -53,4 +52,3 @@ class HelloController { } } ---- - diff --git a/src/main/docs/guide/languageSupport/kotlin/coroutines.adoc b/src/main/docs/guide/languageSupport/kotlin/coroutines.adoc index 49a906fb643..b05b81f0185 100644 --- a/src/main/docs/guide/languageSupport/kotlin/coroutines.adoc +++ b/src/main/docs/guide/languageSupport/kotlin/coroutines.adoc @@ -1,5 +1,4 @@ -Kotlin coroutines allow you to create asynchronous applications with imperative style code. A Micronaut's controller -action can be a `suspend` function: +Kotlin coroutines allow you to create asynchronous applications with imperative style code. A Micronaut controller action can be a `suspend` function: snippet::io.micronaut.docs.server.suspend.SuspendController[tags="suspend", indent=0, title="Controller suspend function example"] @@ -22,13 +21,13 @@ snippet::io.micronaut.docs.streaming.HeadlineFlowController[tags="streamingWithF <1> A method `streamHeadlinesWithFlow` is defined that produces `application/x-json-stream` <2> A `Flow` is created using `flow` -<3> This `Flow` will emit 100 messages -<4> Emitting will happen with `emit` `suspend` function -<5> There will be a 1 second _delay_ between messages +<3> This `Flow` emits 100 messages +<4> Emitting happens with `emit` `suspend` function +<5> There is a one second _delay_ between messages A streaming client can simply return a `Flow`, for example: snippet::io.micronaut.docs.streaming.HeadlineFlowClient[tags="imports, class, streamingWithFlow", indent=0, title="Streaming client with Flow"] <1> The `@Get` method is defined as processing responses of type `APPLICATION_JSON_STREAM` -<2> A `Flow` is used as the return type +<2> The return type is `Flow` diff --git a/src/main/docs/guide/languageSupport/kotlin/gradlekapt.adoc b/src/main/docs/guide/languageSupport/kotlin/gradlekapt.adoc index ebf727f5341..1f5cb63baf3 100644 --- a/src/main/docs/guide/languageSupport/kotlin/gradlekapt.adoc +++ b/src/main/docs/guide/languageSupport/kotlin/gradlekapt.adoc @@ -1,4 +1,4 @@ -To enable gradle incremental annotation processing with Kapt the arguments as specified <> must be sent to Kapt +To enable Gradle incremental annotation processing with Kapt, the arguments as specified in <> must be sent to Kapt. The following example demonstrates how to enable and configure incremental annotation processing for annotations you have defined under the `com.example` and `io.example` packages: @@ -13,4 +13,4 @@ kapt { } ---- -WARNING: If you do not enable processing for custom annotations you define these annotations will simple be ignored by Micronaut which may break your application. \ No newline at end of file +WARNING: If you do not enable processing for your custom annotations, they will be ignored by Micronaut, which may break your application. diff --git a/src/main/docs/guide/languageSupport/kotlin/kaptintellij.adoc b/src/main/docs/guide/languageSupport/kotlin/kaptintellij.adoc index 58490bbd759..17136c1e596 100644 --- a/src/main/docs/guide/languageSupport/kotlin/kaptintellij.adoc +++ b/src/main/docs/guide/languageSupport/kotlin/kaptintellij.adoc @@ -1,6 +1,6 @@ -As of this writing IntelliJ's built-in compiler does not directly support Kapt and annotation processing. You must instead configure Intellij to run Gradle (or Maven) compilation as a build step before running your tests or application class. +As of this writing, IntelliJ's built-in compiler does not directly support Kapt and annotation processing. You must instead configure Intellij to run Gradle (or Maven) compilation as a build step before running your tests or application class. -First edit the run configuration for tests or for the application and select "Run Gradle task" as a build step: +First, edit the run configuration for tests or for the application and select "Run Gradle task" as a build step: image::kotlin-run-1.png[Intellij Settings,1024,768] @@ -8,7 +8,7 @@ Then add the `classes` task as task to execute for the application or for tests image::kotlin-run-2.png[Intellij Settings,1024,768] -Now whenever you run tests or the application Micronaut classes will be generated at compilation time. +Now when you run tests or start the application, Micronaut will generate classes at compile time. Alternatively, you can https://www.jetbrains.com/help/idea/gradle.html#delegate_build_gradle[delegate IntelliJ build/run actions to Gradle] completely: diff --git a/src/main/docs/guide/languageSupport/kotlin/kotlinretainparamnames.adoc b/src/main/docs/guide/languageSupport/kotlin/kotlinretainparamnames.adoc index 85110a170b3..f393542c72b 100644 --- a/src/main/docs/guide/languageSupport/kotlin/kotlinretainparamnames.adoc +++ b/src/main/docs/guide/languageSupport/kotlin/kotlinretainparamnames.adoc @@ -1,6 +1,6 @@ Like with Java, the parameter name data for method parameters is not retained at compile time when using Kotlin. This can be a problem for Micronaut if you do not define parameter names explicitly and depend on an external JAR that is already compiled. -To enable the retention of parameter name data with Kotlin you should set the `javaParameters` option to `true` in your `build.gradle`: +To enable retention of parameter name data with Kotlin, set the `javaParameters` option to `true` in your `build.gradle`: .build.gradle [source,groovy] diff --git a/src/main/docs/guide/languageSupport/kotlin/openandaop.adoc b/src/main/docs/guide/languageSupport/kotlin/openandaop.adoc index 6e2d73a2ced..7a85a50f482 100644 --- a/src/main/docs/guide/languageSupport/kotlin/openandaop.adoc +++ b/src/main/docs/guide/languageSupport/kotlin/openandaop.adoc @@ -1,5 +1,4 @@ -Micronaut provides a compile-time AOP API that does not use reflection. When you use any Micronaut's <>, -it creates a subclass at compile-time to provide the AOP behaviour. This can be a problem because Kotlin classes are final by default. If the application was created with the Micronaut CLI, then the Kotlin link:https://kotlinlang.org/docs/reference/compiler-plugins.html#all-open-compiler-plugin[all-open] plugin is configured for you to automatically change your classes to `open` when an AOP annotation is used. To configure it yourself, simply add the api:io.micronaut.aop.Around[] class to the list of supported annotations. +Micronaut provides a compile-time AOP API that does not use reflection. When you use any Micronaut <>, it creates a subclass at compile-time to provide the AOP behaviour. This can be a problem because Kotlin classes are final by default. If the application was created with the Micronaut CLI, the Kotlin link:https://kotlinlang.org/docs/reference/compiler-plugins.html#all-open-compiler-plugin[all-open] plugin is configured for you to automatically change your classes to `open` when an AOP annotation is used. To configure it yourself, add the api:io.micronaut.aop.Around[] class to the list of supported annotations. If you prefer not to or cannot use the `all-open` plugin, you must declare the classes that are annotated with an AOP annotation to be open: diff --git a/src/main/docs/guide/management/buildingEndpoints.adoc b/src/main/docs/guide/management/buildingEndpoints.adoc index 68a2f896d91..2b0b993c0fe 100644 --- a/src/main/docs/guide/management/buildingEndpoints.adoc +++ b/src/main/docs/guide/management/buildingEndpoints.adoc @@ -1 +1 @@ -In addition to the <>, the `management` dependency also provides support for creating custom endpoints. Custom endpoints can be enabled and configured identically to the built-in endpoints, and can be used to retrieve and return any metrics or other application data that you require. \ No newline at end of file +In addition to the <>, the `management` dependency also provides support for creating custom endpoints. These can be enabled and configured like the built-in endpoints, and can be used to retrieve and return any metrics or other application data. diff --git a/src/main/docs/guide/management/buildingEndpoints/endpointAnnotation.adoc b/src/main/docs/guide/management/buildingEndpoints/endpointAnnotation.adoc index 13fc0c18abc..0abc48c90b8 100644 --- a/src/main/docs/guide/management/buildingEndpoints/endpointAnnotation.adoc +++ b/src/main/docs/guide/management/buildingEndpoints/endpointAnnotation.adoc @@ -9,7 +9,7 @@ class FooEndpoint { } ---- -If a single `String` argument is supplied to the annotation, it will be used as the endpoint id. +If a single `String` argument is supplied to the annotation, it is used as the endpoint id. It is possible to supply additional (named) arguments to the annotation. Other possible arguments to `@Endpoint` are described in the table below: @@ -25,7 +25,6 @@ It is possible to supply additional (named) arguments to the annotation. Other p |Prefix used for configuring the endpoint (see <>) |`@Endpoint(prefix = "foo")` - |`boolean defaultEnabled` |Sets whether the endpoint is enabled when no configuration is set (see <>) |`@Endpoint(defaultEnabled = false)` @@ -38,6 +37,6 @@ It is possible to supply additional (named) arguments to the annotation. Other p == Example of custom Endpoint -The following example `Endpoint` class will create an endpoint accessible at `/date`: +The following example `Endpoint` class creates an endpoint accessible at `/date`: snippet::io.micronaut.docs.server.endpoint.CurrentDateEndpoint[tags="endpointImport, endpointClassBegin, methodSummary, endpointClassEnd", indent=0, title="CurrentDateEndpoint"] diff --git a/src/main/docs/guide/management/buildingEndpoints/endpointConfiguration.adoc b/src/main/docs/guide/management/buildingEndpoints/endpointConfiguration.adoc index 6816df4d9dd..8d63b28cfb2 100644 --- a/src/main/docs/guide/management/buildingEndpoints/endpointConfiguration.adoc +++ b/src/main/docs/guide/management/buildingEndpoints/endpointConfiguration.adoc @@ -11,18 +11,18 @@ class FooEndpoint { } ---- -By default the endpoint will be enabled. To disable the endpoint, set `endpoints.foo.enabled` to false. If `endpoints.foo.enabled` is not set at all and `endpoints.all.enabled` is set to false, the endpoint will be disabled. +By default the endpoint is enabled. To disable it, set `endpoints.foo.enabled` to false. If `endpoints.foo.enabled` is not set and `endpoints.all.enabled` is `false`, the endpoint will be disabled. -The configuration values for the endpoint override the ones for `all`. If `endpoints.foo.enabled` is explicitly set to `true` and `endpoints.all.enabled` is explicitly set to `false`, the endpoint will be enabled. +The configuration values for the endpoint override those for `all`. If `endpoints.foo.enabled` is `true` and `endpoints.all.enabled` is `false`, the endpoint will be enabled. For all endpoints, the following configuration values can be set. [source,yaml] ---- endpoints: - : - enabled: Boolean - sensitive: Boolean + : + enabled: Boolean + sensitive: Boolean ---- -NOTE: The base path for all endpoints is `/` by default. If you prefer the endpoints to be available under a different base path, configure `endpoints.all.path`. For example, if the value is set to `/endpoints`, the foo endpoint will be accessible at `/endpoints/foo`. \ No newline at end of file +NOTE: The base path for all endpoints is `/` by default. If you prefer the endpoints to be available under a different base path, configure `endpoints.all.path`. For example, if the value is set to `/endpoints`, the foo endpoint will be accessible at `/endpoints/foo`. diff --git a/src/main/docs/guide/management/buildingEndpoints/endpointMethod.adoc b/src/main/docs/guide/management/buildingEndpoints/endpointMethod.adoc index 05b89c569a4..24723653feb 100644 --- a/src/main/docs/guide/management/buildingEndpoints/endpointMethod.adoc +++ b/src/main/docs/guide/management/buildingEndpoints/endpointMethod.adoc @@ -1,4 +1,4 @@ -Endpoints respond to `GET` ("read"), `POST` ("write") and `DELETE` ("delete") requests. To return a response from an endpoint, annotate its public method/s with one of following annotations: +Endpoints respond to `GET` ("read"), `POST` ("write") and `DELETE` ("delete") requests. To return a response from an endpoint, annotate its public method(s) with one of the following annotations: .Endpoint Method Annotations |=== @@ -17,7 +17,7 @@ Endpoints respond to `GET` ("read"), `POST` ("write") and `DELETE` ("delete") re == Read Methods -Annotating a method with the api:management.endpoint.annotation.Read[] annotation will cause it to respond to `GET` requests. +Annotating a method with the api:management.endpoint.annotation.Read[] annotation causes it to respond to `GET` requests. snippet::io.micronaut.docs.server.endpoint.CurrentDateEndpoint[tags="endpointImport, readImport, endpointClassBegin, currentDate, simpleRead, endpointClassEnd", indent=0, title="CurrentDateEndpoint"] @@ -45,10 +45,9 @@ $ curl -X GET localhost:8080/date/the_date_is the_date_is: Fri May 11 19:24:21 CDT ---- - == Write Methods -Annotating a method with the api:management.endpoint.Write[] annotation will cause it to respond to `POST` requests. +Annotating a method with the api:management.endpoint.Write[] annotation causes it to respond to `POST` requests. snippet::io.micronaut.docs.server.endpoint.CurrentDateEndpoint[tags="endpointImport, writeImport, mediaTypeImport, endpointClassBegin, currentDate, simpleWrite, endpointClassEnd", indent=0, title="CurrentDateEndpoint"] @@ -74,10 +73,9 @@ $ curl -X POST http://localhost:65013/message -H 'Content-Type: application/x-ww Message updated ---- - == Delete Methods -Annotating a method with the api:management.endpoint.Delete[] annotation will cause it to respond to `DELETE` requests. +Annotating a method with the api:management.endpoint.Delete[] annotation causes it to respond to `DELETE` requests. snippet::io.micronaut.docs.server.endpoint.MessageEndpoint[tags="endpointImport, deleteImport, endpointClassBegin, message, simpleDelete, endpointClassEnd", indent=0, title="MessageEndpoint"] diff --git a/src/main/docs/guide/management/buildingEndpoints/endpointSensitivity.adoc b/src/main/docs/guide/management/buildingEndpoints/endpointSensitivity.adoc index 56a5dce2862..e1d31c2324c 100644 --- a/src/main/docs/guide/management/buildingEndpoints/endpointSensitivity.adoc +++ b/src/main/docs/guide/management/buildingEndpoints/endpointSensitivity.adoc @@ -2,14 +2,14 @@ Endpoint sensitivity can be controlled for the entire endpoint through the endpo snippet::io.micronaut.docs.server.endpoint.AlertsEndpoint[tags="imports,clazz", indent=0, title="AlertsEndpoint"] -<1> The endpoint is not sensitive by default and the default prefix of `endpoints` is used. +<1> The endpoint is not sensitive by default, and the default prefix of `endpoints` is used. <2> This method is always sensitive, regardless of any other factors <3> The `property` value is appended to the prefix and id to lookup a configuration value -If the configuration key `endpoints.alerts.add.sensitive` is set, that value will determine the sensitivity of the `addAlert` method. +If the configuration key `endpoints.alerts.add.sensitive` is set, that value determines the sensitivity of the `addAlert` method. -1. `endpoint` is the first token because that is the default value for `prefix` in the endpoint annotation and is not set explicity in this example. -2. `alerts` is the next token because that is the endpoint id -3. `add.sensitive` is the next token because that is the value set to the `property` member of the ann:io.micronaut.management.endpoint.annotation.Sensitive[] annotation. +. `endpoint` is the first token because that is the default value for `prefix` in the endpoint annotation and is not set explicitly in this example. +. `alerts` is the next token because that is the endpoint id +. `add.sensitive` is the next token because that is the value set to the `property` member of the ann:io.micronaut.management.endpoint.annotation.Sensitive[] annotation. -If the configuration key is not set, the `defaultValue` will be used (defaults to `true`). +If the configuration key is not set, the `defaultValue` is used (defaults to `true`). diff --git a/src/main/docs/guide/management/providedEndpoints.adoc b/src/main/docs/guide/management/providedEndpoints.adoc index 7104c5d3764..7345cc8ddd3 100644 --- a/src/main/docs/guide/management/providedEndpoints.adoc +++ b/src/main/docs/guide/management/providedEndpoints.adoc @@ -63,7 +63,7 @@ this should be used with care because private and sensitive information will be === Management Port -By default all management endpoints are exposed over the same port as the application. You can alter this behaviour by specifying the `endpoints.all.port` setting: +By default, all management endpoints are exposed over the same port as the application. You can alter this behaviour by specifying the `endpoints.all.port` setting: [source,yaml] ---- @@ -72,7 +72,7 @@ endpoints: port: 8085 ---- -In the above example the management endpoints will be exposed only over port 8085. +In the above example the management endpoints are exposed only over port 8085. === JMX diff --git a/src/main/docs/guide/management/providedEndpoints/beansEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/beansEndpoint.adoc index 66fb2506f66..a59a144ca8a 100644 --- a/src/main/docs/guide/management/providedEndpoints/beansEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/beansEndpoint.adoc @@ -17,6 +17,6 @@ endpoints: == Customization -The beans endpoint is composed of a bean definition data collector and a bean data implementation. The bean definition data collector (link:{api}/io/micronaut/management/endpoint/beans/BeanDefinitionDataCollector.html[BeanDefinitionDataCollector]) is responsible for returning a publisher that will return the data used in the response. The bean definition data (link:{api}/io/micronaut/management/endpoint/beans/BeanDefinitionData.html[BeanDefinitionData]) is responsible for returning data about an individual bean definition. +The beans endpoint is composed of a bean definition data collector and a bean data implementation. The bean definition data collector (link:{api}/io/micronaut/management/endpoint/beans/BeanDefinitionDataCollector.html[BeanDefinitionDataCollector]) is responsible for returning a publisher that returns the data used in the response. The bean definition data (link:{api}/io/micronaut/management/endpoint/beans/BeanDefinitionData.html[BeanDefinitionData]) is responsible for returning data about an individual bean definition. To override the default behavior for either of the helper classes, either extend the default implementations (link:{api}/io/micronaut/management/endpoint/beans/impl/RxJavaBeanDefinitionDataCollector.html[RxJavaBeanDefinitionDataCollector], link:{api}/io/micronaut/management/endpoint/beans/impl/DefaultBeanDefinitionData.html[DefaultBeanDefinitionData]), or implement the relevant interface directly. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the default implementation. diff --git a/src/main/docs/guide/management/providedEndpoints/environmentEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/environmentEndpoint.adoc index 5b2fa79b9cc..45b95249faf 100644 --- a/src/main/docs/guide/management/providedEndpoints/environmentEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/environmentEndpoint.adoc @@ -1,6 +1,6 @@ The environment endpoint returns information about the link:{api}/io/micronaut/context/env/Environment.html[Environment] and its link:{api}/io/micronaut/context/env/PropertySource.html[PropertySource]s. -NOTE: Properties that may contain sensitive data will be masked. +NOTE: Properties that may contain sensitive data are masked. == Configuration diff --git a/src/main/docs/guide/management/providedEndpoints/healthEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/healthEndpoint.adoc index 71029a842bb..1010e8a6fcc 100644 --- a/src/main/docs/guide/management/providedEndpoints/healthEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/healthEndpoint.adoc @@ -1,4 +1,4 @@ -The health endpoint returns information about the "health" of the application. The application health is determined by any number of "health indicators". +The health endpoint returns information about the "health" of the application, which is determined by any number of "health indicators". To execute the health endpoint, send a GET request to /health. Additionally the health endpoint exposes /health/liveness and /health/readiness health indicators. @@ -20,9 +20,9 @@ endpoints: <1> One of api:management.endpoint.health.DetailsVisibility[] -The `details-visible` setting is used to control whether health detail should be exposed to users who are not authenticated. +The `details-visible` setting controls whether health detail will be exposed to users who are not authenticated. -For example setting: +For example, setting: .Using `details-visible` [source,yaml] @@ -32,9 +32,9 @@ endpoints: details-visible: ANONYMOUS ---- -Will expose detailed information read from the various health indicators about the health status of the application to anonymous unauthenticated users. +exposes detailed information from the various health indicators about the health status of the application to anonymous unauthenticated users. -The `endpoints.health.status.http-mapping` setting can be used to control what status codes are returned for each health status. The defaults are described in the table below: +The `endpoints.health.status.http-mapping` setting controls which status codes to return for each health status. The defaults are described in the table below: |=== |Status | HTTP Code @@ -62,15 +62,15 @@ endpoints: DOWN: 200 ---- -The above will return api:http.HttpStatus#OK[] (200) even when the api:health.HealthStatus[] is api:health.HealthStatus#DOWN[]. +The above returns api:http.HttpStatus#OK[] (200) even when the api:health.HealthStatus[] is api:health.HealthStatus#DOWN[]. == Customization -The health endpoint consists of a health aggregator and any number of health indicators. To add a health indicator, simply create a bean class that implements link:{api}/io/micronaut/management/health/indicator/HealthIndicator.html[HealthIndicator]. It is recommended to also use either link:{api}/io/micronaut/health/indicator/annotation/Liveness.html[@Liveness] or link:{api}/io/micronaut/health/indicator/annotation/Readiness.html[@Readiness] qualifier. If no qualifier is used then the health incidator is part of /health and /health/readiness endpoints. A base class link:{api}/io/micronaut/management/health/indicator/AbstractHealthIndicator.html[AbstractHealthIndicator] has been provided for you to extend to make the process easier. +The health endpoint consists of a health aggregator and any number of health indicators. To add a health indicator, create a bean class that implements link:{api}/io/micronaut/management/health/indicator/HealthIndicator.html[HealthIndicator]. It is recommended to also use either link:{api}/io/micronaut/health/indicator/annotation/Liveness.html[@Liveness] or link:{api}/io/micronaut/health/indicator/annotation/Readiness.html[@Readiness] qualifier. If no qualifier is used, the health indicator will be part of /health and /health/readiness endpoints. A base class link:{api}/io/micronaut/management/health/indicator/AbstractHealthIndicator.html[AbstractHealthIndicator] is available to subclass to make the process easier. -All of the health indicator beans will be collected together with the health aggregator. To provide your own implementation of the health aggregator, create a class that implements link:{api}/io/micronaut/management/health/aggregator/HealthAggregator.html[HealthAggregator] and register it as a bean. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the link:{api}/io/micronaut/management/health/aggregator/RxJavaHealthAggregator.html[default implementation]. +All health indicator beans are collected together with the health aggregator. To provide your own implementation of the health aggregator, create a class that implements link:{api}/io/micronaut/management/health/aggregator/HealthAggregator.html[HealthAggregator] and register it as a bean. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the link:{api}/io/micronaut/management/health/aggregator/RxJavaHealthAggregator.html[default implementation]. -The default health aggregator returns an overall status that is calculated based on the health statuses of the indicators. A link:{api}/io/micronaut/health/HealthStatus.html[health status] consists of several pieces of information. +The default health aggregator returns an overall status calculated based on the health statuses of the indicators. A link:{api}/io/micronaut/health/HealthStatus.html[health status] consists of several pieces of information. |======= |Name |The name of the status @@ -79,11 +79,11 @@ The default health aggregator returns an overall status that is calculated based |Severity |How severe the status is. A higher number is more severe |======= -The "worst" status will be returned as the overall status. A non operational status will be selected over an operational status. A higher severity will be selected over a lower severity. +The "worst" status is returned as the overall status. A non-operational status is selected over an operational status. A higher severity is selected over a lower severity. == Provided Indicators -All micronaut provided health indicators are exposed on /health and /health/readiness endpoints. +All Micronaut provided health indicators are exposed on /health and /health/readiness endpoints. === Disk Space @@ -108,4 +108,4 @@ The JDBC health indicator determines the health of your application based on the === Discovery Client -If your application is using service discovery, a health indicator will be included to monitor the health of the discovery client. The data returned can include a list of the services available. +If your application uses service discovery, a health indicator is included to monitor the health of the discovery client. The data returned can include a list of the services available. diff --git a/src/main/docs/guide/management/providedEndpoints/infoEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/infoEndpoint.adoc index 5b46d244176..f280ad6055d 100644 --- a/src/main/docs/guide/management/providedEndpoints/infoEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/infoEndpoint.adoc @@ -17,17 +17,17 @@ endpoints: == Customization -The info endpoint consists of an info aggregator and any number of info sources. To add an info source, simply create a bean class that implements link:{api}/io/micronaut/management/endpoint/info/InfoSource.html[InfoSource]. If your info source needs to retrieve data from Java properties files, you can extend the link:{api}/io/micronaut/management/endpoint/info/source/PropertiesInfoSource.html[PropertiesInfoSource] interface which provides a helper method for this purpose. +The info endpoint consists of an info aggregator and any number of info sources. To add an info source, create a bean class that implements link:{api}/io/micronaut/management/endpoint/info/InfoSource.html[InfoSource]. If your info source needs to retrieve data from Java properties files, extend the link:{api}/io/micronaut/management/endpoint/info/source/PropertiesInfoSource.html[PropertiesInfoSource] interface which provides a helper method for this purpose. -All of the info source beans will be collected together with the info aggregator. To provide your own implementation of the info aggregator, create a class that implements link:{api}/io/micronaut/management/endpoint/info/InfoAggregator.html[InfoAggregator] and register it as a bean. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the link:{api}/io/micronaut/management/endpoint/info/impl/RxInfoAggregator.html[default implementation]. +All info source beans are collected together with the info aggregator. To provide your own implementation of the info aggregator, create a class that implements link:{api}/io/micronaut/management/endpoint/info/InfoAggregator.html[InfoAggregator] and register it as a bean. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the link:{api}/io/micronaut/management/endpoint/info/impl/RxInfoAggregator.html[default implementation]. -The default info aggregator returns map containing the combined properties returned by all the info sources. This map is returned as JSON from the /info endpoint. +The default info aggregator returns a map containing the combined properties returned by all the info sources. This map is returned as JSON from the /info endpoint. == Provided Info Sources === Configuration Info Source -The link:{api}/io/micronaut/management/endpoint/info/source/ConfigurationInfoSource.html[ConfigurationInfoSource] will return configuration properties under the `info` key. In addition to string, integer and boolean values, more complex properties can be exposed as maps in the JSON output (if the configuration format supports it). +The link:{api}/io/micronaut/management/endpoint/info/source/ConfigurationInfoSource.html[ConfigurationInfoSource] returns configuration properties under the `info` key. In addition to string, integer and boolean values, more complex properties can be exposed as maps in the JSON output (if the configuration format supports it). .Info Source Example (`application.groovy`) [source,groovy] @@ -37,7 +37,7 @@ info.demo.number = 123 info.demo.map = [key: 'value', other_key: 123] ---- -The above config will result in the following JSON response from the info endpoint: +The above config results in the following JSON response from the info endpoint: [source,json] ---- @@ -59,20 +59,20 @@ The configuration info source can be disabled using the `endpoints.info.config.e === Git Info Source -If a `git.properties` file is available on the classpath, the link:{api}/io/micronaut/management/endpoint/info/source/GitInfoSource.html[GitInfoSource] will expose the values in that file under the `git` key. Generating of a `git.properties` file will need to be configured as part of your build. One easy option for Gradle users is the https://plugins.gradle.org/plugin/com.gorylenko.gradle-git-properties[Gradle Git Properties Plugin]. Maven users can look at the https://github.com/git-commit-id/maven-git-commit-id-plugin[Maven Git Commit Id Plugin]. +If a `git.properties` file is available on the classpath, the link:{api}/io/micronaut/management/endpoint/info/source/GitInfoSource.html[GitInfoSource] exposes the values in that file under the `git` key. Generating of a `git.properties` file must be configured as part of your build. One easy option for Gradle users is the https://plugins.gradle.org/plugin/com.gorylenko.gradle-git-properties[Gradle Git Properties Plugin]. Maven users can use the https://github.com/git-commit-id/maven-git-commit-id-plugin[Maven Git Commit ID Plugin]. ==== Configuration -To specify an alternate path/name of the properties file, you can supply a custom value in the `endpoints.info.git.location` property. +To specify an alternate path or name of the properties file, supply a custom value in the `endpoints.info.git.location` property. The git info source can be disabled using the `endpoints.info.git.enabled` property. === Build Info Source -If a `META-INF/build-info.properties` file is available on the classpath, the link:{api}/io/micronaut/management/endpoint/info/source/BuildInfoSource.html[BuildInfoSource] will expose the values in that file under the `build` key. Generating of a `build-info.properties` file will need to be configured as part of your build. One easy option for Gradle users is the https://plugins.gradle.org/plugin/com.pasam.gradle.buildinfo[Gradle Build Info Plugin]. Another option for Maven users is the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/build-info.html[Spring Boot Maven Plugin] +If a `META-INF/build-info.properties` file is available on the classpath, the link:{api}/io/micronaut/management/endpoint/info/source/BuildInfoSource.html[BuildInfoSource] exposes the values in that file under the `build` key. Generating a `build-info.properties` file must be configured as part of your build. One easy option for Gradle users is the https://plugins.gradle.org/plugin/com.pasam.gradle.buildinfo[Gradle Build Info Plugin]. An option for Maven users is the https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/build-info.html[Spring Boot Maven Plugin] ==== Configuration -To specify an alternate path/name of the properties file, you can supply a custom value in the `endpoints.info.build.location` property. +To specify an alternate path/name of the properties file, supply a custom value in the `endpoints.info.build.location` property. The build info source can be disabled using the `endpoints.info.build.enabled` property. diff --git a/src/main/docs/guide/management/providedEndpoints/loggersEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/loggersEndpoint.adoc index b9d3da5d4d1..3315981842a 100644 --- a/src/main/docs/guide/management/providedEndpoints/loggersEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/loggersEndpoint.adoc @@ -1,10 +1,8 @@ -The loggers endpoint returns information about the available loggers in the application and -permits configuring the their log level. +The loggers endpoint returns information about the available loggers in the application and permits configuring their log level. -NOTE: The loggers endpoint is disabled by default and needs to be explicitly enabled with the setting `endpoints.loggers.enabled=true`. +NOTE: The loggers endpoint is disabled by default and must be explicitly enabled with the setting `endpoints.loggers.enabled=true`. -To get a collection of all loggers by name with their configured and effective log levels, -send a GET request to /loggers. This will also provide a list of the available log levels. +To get a collection of all loggers by name with their configured and effective log levels, send a GET request to /loggers. This also provides a list of the available log levels. [source,bash] ---- @@ -32,8 +30,7 @@ $ curl http://localhost:8080/loggers } ---- -To get the log levels of a particular logger, include the logger name in your GET request. For -example, to access the log levels of the logger 'io.micronaut.http': +To get the log levels of a particular logger, include the logger name in your GET request. For example, to access the log levels of the logger 'io.micronaut.http': [source,bash] ---- @@ -45,11 +42,9 @@ $ curl http://localhost:8080/loggers/io.micronaut.http } ---- -If the named logger does not exist, it will be created with an unspecified (i.e. `NOT_SPECIFIED`) -configured log level. (It's effective log level will usually be that of the root logger.) +If the named logger does not exist, it is created with an unspecified (i.e. `NOT_SPECIFIED`) configured log level (its effective log level is usually that of the root logger). -To update the log level of a single logger, send a POST request to the named logger URL and include -a body providing the log level to configure. +To update the log level of a single logger, send a POST request to the named logger URL and include a body providing the log level to configure. [source,bash] ---- @@ -81,8 +76,7 @@ endpoints: sensitive: Boolean ---- -NOTE: By default the endpoint doesn't allow to change the log level by unauthorized users (even if `sensitive` is set to -`false`). To allow it is necessary set `endpoints.loggers.write-sensitive` to `false`. +NOTE: By default, the endpoint doesn't allow changing the log level by unauthorized users (even if `sensitive` is set to `false`). To allow this you must set `endpoints.loggers.write-sensitive` to `false`. == Customization @@ -90,29 +84,16 @@ The loggers endpoint is composed of two customizable parts: a loggers manager an The loggers manager (link:{api}/io/micronaut/management/endpoint/loggers/LoggersManager.html[LoggersManager]) -is responsible for returning a Publisher that will return data collected and transformed for the response, -and it is also responsible for updating a logger with a new log level. +is responsible for returning a Publisher that returns data collected and transformed for the response, and it is also responsible for updating a logger with a new log level. -To override the default behavior for the loggers manager, either extend the default implementation -(link:{api}/io/micronaut/management/endpoint/loggers/impl/DefaultLoggersManager.html[DefaultLoggersManager]) -or implement the link:{api}/io/micronaut/management/endpoint/loggers/LoggersManager.html[LoggersManager] -interface directly. To ensure your implementation is used instead of the default, add the -link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the -value being the default implementation. +To override the default behavior for the loggers manager, either extend the default implementation (link:{api}/io/micronaut/management/endpoint/loggers/impl/DefaultLoggersManager.html[DefaultLoggersManager]) or implement the link:{api}/io/micronaut/management/endpoint/loggers/LoggersManager.html[LoggersManager] interface directly. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the default implementation. The logging system (link:{api}/io/micronaut/management/endpoint/loggers/LoggingSystem.html[LoggingSystem]) is responsible for processing requests from the loggers manager against a particular logging library (e.g. logback, log4j, etc.) -The current default implementation for the logging system is -link:{api}/io/micronaut/management/endpoint/loggers/impl/LogbackLoggingSystem.html[LogbackLoggingSystem], -which works with the https://logback.qos.ch/[logback] logging framework. Additional logging systems will -be implemented in future revisions of Micronaut. For custom logging system behavior, implement -the link:{api}/io/micronaut/management/endpoint/loggers/LoggingSystem.html[LoggingSystem] interface directly. -To ensure your implementation is used instead of the default, add the -link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the -value being the default implementation. +The current default implementation for the logging system is link:{api}/io/micronaut/management/endpoint/loggers/impl/LogbackLoggingSystem.html[LogbackLoggingSystem], which works with the https://logback.qos.ch/[logback] logging framework. Additional logging systems will be implemented in future revisions of Micronaut. For custom logging system behavior, implement the link:{api}/io/micronaut/management/endpoint/loggers/LoggingSystem.html[LoggingSystem] interface directly. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the default implementation. [source,java] ---- diff --git a/src/main/docs/guide/management/providedEndpoints/metricsEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/metricsEndpoint.adoc index 4a9f3fcecaa..34037aacaa8 100644 --- a/src/main/docs/guide/management/providedEndpoints/metricsEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/metricsEndpoint.adoc @@ -1,16 +1,16 @@ -Micronaut includes the ability to expose Metrics via integration with http://micrometer.io[Micrometer]. +Micronaut can expose application metrics via integration with http://micrometer.io[Micrometer]. [TIP] .Using the CLI ==== -If you are creating your project using the Micronaut CLI, supply one of the micrometer features to enable metrics and preconfigure the selected registery in your project. For example: +If you create your project using the Micronaut CLI, supply one of the micrometer features to enable metrics and preconfigure the selected registry in your project. For example: ---- $ mn create-app my-app --features micrometer-atlas ---- ==== -The metrics endpoint returns information about the "metrics" of the application. To execute the metrics endpoint, send a GET request to `/metrics`. This will return a list of available metric names. +The metrics endpoint returns information about the "metrics" of the application. To execute the metrics endpoint, send a GET request to `/metrics`. This returns a list of available metric names. You can get specific metrics by using `/metrics/[name]` such as `/metrics/jvm.memory.used`. -See the documentation for https://micronaut-projects.github.io/micronaut-micrometer/latest/guide/[Micronaut Micrometer] for a list of registries and information on how to configure, expose and customize metrics output. \ No newline at end of file +See the documentation for https://micronaut-projects.github.io/micronaut-micrometer/latest/guide/[Micronaut Micrometer] for a list of registries and information on how to configure, expose and customize metrics output. diff --git a/src/main/docs/guide/management/providedEndpoints/refreshEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/refreshEndpoint.adoc index ab9c386a29c..d182f31734b 100644 --- a/src/main/docs/guide/management/providedEndpoints/refreshEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/refreshEndpoint.adoc @@ -1,4 +1,4 @@ -The refresh endpoint will refresh the application state, causing all link:{api}/io/micronaut/runtime/context/scope/Refreshable.html[Refreshable] beans in the context to be destroyed and reinstantiated upon further requests. This is accomplished by publishing a api:runtime.context.scope.refresh.RefreshEvent[] in the Application Context. +The refresh endpoint refreshes the application state, causing all link:{api}/io/micronaut/runtime/context/scope/Refreshable.html[Refreshable] beans in the context to be destroyed and reinstantiated upon further requests. This is accomplished by publishing a api:runtime.context.scope.refresh.RefreshEvent[] in the Application Context. To execute the refresh endpoint, send a POST request to /refresh. @@ -7,7 +7,7 @@ To execute the refresh endpoint, send a POST request to /refresh. $ curl -X POST http://localhost:8080/refresh ---- -When executed without a body, the endpoint will first refresh the link:{api}/io/micronaut/context/env/Environment.html[Environment] and perform a diff to detect any changes, and will then only perform the refresh if changes are detected. To skip this check and refresh all `@Refreshable` beans regardless of environment changes (e.g., to force refresh of cached responses from third-party services), you can supply a `force` parameter in the POST request body. +When executed without a body, the endpoint first refreshes the link:{api}/io/micronaut/context/env/Environment.html[Environment] and performs a diff to detect any changes, and then only performs the refresh if changes are detected. To skip this check and refresh all `@Refreshable` beans regardless of environment changes (e.g., to force refresh of cached responses from third-party services), add a `force` parameter in the POST request body. [source,bash] ---- diff --git a/src/main/docs/guide/management/providedEndpoints/routesEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/routesEndpoint.adoc index 08051bbdb70..a93309367f0 100644 --- a/src/main/docs/guide/management/providedEndpoints/routesEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/routesEndpoint.adoc @@ -17,6 +17,6 @@ endpoints: == Customization -The routes endpoint is composed of a route data collector and a route data implementation. The route data collector (link:{api}/io/micronaut/management/endpoint/routes/RouteDataCollector.html[RouteDataCollector]) is responsible for returning a publisher that will return the data used in the response. The route data (link:{api}/io/micronaut/management/endpoint/routes/RouteData.html[RouteData]) is responsible for returning data about an individual route. +The routes endpoint is composed of a route data collector and a route data implementation. The route data collector (link:{api}/io/micronaut/management/endpoint/routes/RouteDataCollector.html[RouteDataCollector]) is responsible for returning a publisher that returns the data used in the response. The route data (link:{api}/io/micronaut/management/endpoint/routes/RouteData.html[RouteData]) is responsible for returning data about an individual route. To override the default behavior for either of the helper classes, either extend the default implementations (link:{api}/io/micronaut/management/endpoint/routes/impl/RxJavaRouteDataCollector.html[RxJavaRouteDataCollector], link:{api}/io/micronaut/management/endpoint/routes/impl/DefaultRouteData.html[DefaultRouteData]), or implement the relevant interface directly. To ensure your implementation is used instead of the default, add the link:{api}/io/micronaut/context/annotation/Replaces.html[@Replaces] annotation to your class with the value being the default implementation. diff --git a/src/main/docs/guide/management/providedEndpoints/stopEndpoint.adoc b/src/main/docs/guide/management/providedEndpoints/stopEndpoint.adoc index 560a1fd3af9..4a761fcba2b 100644 --- a/src/main/docs/guide/management/providedEndpoints/stopEndpoint.adoc +++ b/src/main/docs/guide/management/providedEndpoints/stopEndpoint.adoc @@ -15,4 +15,4 @@ endpoints: sensitive: Boolean ---- -NOTE: By default, the stop endpoint is disabled and needs to be explicitly enabled to be used. +NOTE: By default, the stop endpoint is disabled and must be explicitly enabled to be used. diff --git a/src/main/docs/guide/messaging/kafka.adoc b/src/main/docs/guide/messaging/kafka.adoc index afaec82e3e5..1d6d3b1a82d 100644 --- a/src/main/docs/guide/messaging/kafka.adoc +++ b/src/main/docs/guide/messaging/kafka.adoc @@ -1,8 +1,7 @@ https://kafka.apache.org[Apache Kafka] is a distributed stream processing platform that can be used for a range of messaging requirements in addition to stream processing and real-time data handling. - Micronaut features dedicated support for defining both Kafka `Producer` and `Consumer` instances. Micronaut applications built with Kafka can be deployed with or without the presence of an HTTP server. With Micronaut's efficient compile-time AOP and cloud native features, writing efficient Kafka consumer applications that use very little resources is a breeze. -See the documentation for https://micronaut-projects.github.io/micronaut-kafka/latest/guide[Micronaut Kafka] for more information on how to build Kafka applications with Micronaut. \ No newline at end of file +See the documentation for https://micronaut-projects.github.io/micronaut-kafka/latest/guide[Micronaut Kafka] for more information on how to build Kafka applications with Micronaut. diff --git a/src/main/docs/guide/messaging/nats.adoc b/src/main/docs/guide/messaging/nats.adoc index 1476f8f75ea..cf8eb2b9e7a 100644 --- a/src/main/docs/guide/messaging/nats.adoc +++ b/src/main/docs/guide/messaging/nats.adoc @@ -1,6 +1,6 @@ -https://nats.io/[Nats.io] is a simple, secure and high performance open source messaging system for cloud native applications, IoT messaging, and microservices architectures. +https://nats.io/[Nats.io] is a simple, secure, and high-performance open source messaging system for cloud native applications, IoT messaging, and microservices architectures. -Micronaut features dedicated support for defining both Nats.io publishers and consumers. Micronaut applications built with Nats.io can be deployed with or without the presence of an HTTP server. +Micronaut features dedicated support for defining both Nats.io publishers and consumers. Micronaut applications built with Nats.io can be deployed with or without an HTTP server. With Micronaut's efficient compile-time AOP, using Nats.io has never been easier. Support has been added for publisher confirms and RPC through reactive streams. diff --git a/src/main/docs/guide/messaging/rabbitmq.adoc b/src/main/docs/guide/messaging/rabbitmq.adoc index d328d68c27c..c8d9b321077 100644 --- a/src/main/docs/guide/messaging/rabbitmq.adoc +++ b/src/main/docs/guide/messaging/rabbitmq.adoc @@ -1,7 +1,7 @@ https://www.rabbitmq.com[RabbitMQ] is the most widely deployed open source message broker. -Micronaut features dedicated support for defining both RabbitMQ publishers and consumers. Micronaut applications built with RabbitMQ can be deployed with or without the presence of an HTTP server. +Micronaut features dedicated support for defining both RabbitMQ publishers and consumers. Micronaut applications built with RabbitMQ can be deployed with or without an HTTP server. With Micronaut's efficient compile-time AOP, using RabbitMQ has never been easier. Support has been added for publisher confirms and RPC through reactive streams. -See the documentation for https://micronaut-projects.github.io/micronaut-rabbitmq/latest/guide[Micronaut RabbitMQ] for more information on how to build RabbitMQ applications with Micronaut. \ No newline at end of file +See the documentation for https://micronaut-projects.github.io/micronaut-rabbitmq/latest/guide[Micronaut RabbitMQ] for more information on how to build RabbitMQ applications with Micronaut. diff --git a/src/main/docs/guide/quickStart/buildCLI.adoc b/src/main/docs/guide/quickStart/buildCLI.adoc index ba1a16386d1..032c2222b84 100644 --- a/src/main/docs/guide/quickStart/buildCLI.adoc +++ b/src/main/docs/guide/quickStart/buildCLI.adoc @@ -1,3 +1,3 @@ The best way to install Micronaut on Unix systems is with http://sdkman.io/[SDKMAN] which greatly simplifies installing and managing multiple Micronaut versions. -To see all the available installation methods, check the https://micronaut-projects.github.io/micronaut-starter/latest/guide/#installation[Micronaut Starter documentation]. \ No newline at end of file +To see all available installation methods, check the https://micronaut-projects.github.io/micronaut-starter/latest/guide/#installation[Micronaut Starter documentation]. diff --git a/src/main/docs/guide/quickStart/creatingClient.adoc b/src/main/docs/guide/quickStart/creatingClient.adoc index f03dc6c2c5c..05c5681b86f 100644 --- a/src/main/docs/guide/quickStart/creatingClient.adoc +++ b/src/main/docs/guide/quickStart/creatingClient.adoc @@ -1,4 +1,4 @@ -As mentioned previously, Micronaut includes both an <> and an <>. A <> is provided out of the box which you can use to test the `HelloController` created in the previous section. +As mentioned previously, Micronaut includes both an <> and an <>. A <> is provided which you can use to test the `HelloController` created in the previous section. .Testing Hello World @@ -6,31 +6,31 @@ snippet::io.micronaut.docs.server.intro.HelloControllerSpec[tags="imports,class" <1> The api:runtime.server.EmbeddedServer[] is configured as a shared test field <2> A api:http.client.HttpClient[] instance shared field is also defined -<3> The test using the `toBlocking()` method to make a blocking call -<4> The `retrieve` method returns the response of the controller as a `String` +<3> The test uses the `toBlocking()` method to make a blocking call +<4> The `retrieve` method returns the controller response as a `String` In addition to a low-level client, Micronaut features a <>, powered by the api:http.client.annotation.Client[] annotation. -To create a client, simply create an interface annotated with `@Client`. For example: +To create a client, create an interface annotated with `@Client`, for example: .src/main/java/hello/world/HelloClient.java snippet::io.micronaut.docs.server.intro.HelloClient[tags="imports,class",indent=0] -<1> The `@Client` annotation is used with value that is a relative path to the current server +<1> The `@Client` annotation is used with a value that is a relative path to the current server <2> The same ann:http.annotation.Get[] annotation used on the server is used to define the client mapping -<3> A RxJava rx:Single[] is returned with the value read from the server +<3> An RxJava rx:Single[] is returned with the value read from the server -To test the `HelloClient` simply retrieve it from the api:context.ApplicationContext[] associated with the server: +To test the `HelloClient`, retrieve it from the api:context.ApplicationContext[] associated with the server: .Testing HelloClient snippet::io.micronaut.docs.server.intro.HelloClientSpec[tags="imports,class",indent=0] -<1> The `@MicronautTest` annotation is used to define the test +<1> The `@MicronautTest` annotation defines the test <2> The `HelloClient` is injected from the api:context.ApplicationContext[] -<3> The client is invoked using RxJava's `blockingGet` method +<3> The client is invoked using the RxJava `blockingGet` method -The api:http.client.annotation.Client[] annotation produces an implementation automatically for you at compile time without the need to use proxies or runtime reflection. +The api:http.client.annotation.Client[] annotation produces an implementation automatically for you at compile time without the using proxies or runtime reflection. The api:http.client.annotation.Client[] annotation is very flexible. See the section on the <> for more information. diff --git a/src/main/docs/guide/quickStart/creatingServer.adoc b/src/main/docs/guide/quickStart/creatingServer.adoc index 2c8f62657f2..cf453a4acb6 100644 --- a/src/main/docs/guide/quickStart/creatingServer.adoc +++ b/src/main/docs/guide/quickStart/creatingServer.adoc @@ -1,19 +1,19 @@ Although not required to use Micronaut, the Micronaut CLI is the quickest way to create a new server application. -Using the CLI you can create a new Micronaut application in either Groovy, Java or Kotlin (the default is Java). +Using the CLI you can create a new Micronaut application in either Groovy, Java, or Kotlin (the default is Java). The following command creates a new "Hello World" server application in Java with a Gradle build: -NOTE: The applications generated via our CLI come with Gradle or Maven wrappers, so its not even necessary to have Gradle or Maven installed on your machine to begin running the applications. Simply use the `mvnw` or `gradlew` command, as explained further below. +NOTE: Applications generated via our CLI include Gradle or Maven wrappers, so it is not even necessary to have Gradle or Maven installed on your machine to begin running the applications. Simply use the `mvnw` or `gradlew` command, as explained further below. [source,bash] ---- $ mn create-app hello-world ---- -TIP: You can supply `--build maven` if you wish to create a Maven based build instead +TIP: Supply `--build maven` to create a Maven-based build instead -The previous command will create a new Java application in a directory called `hello-world` featuring a Gradle build. The application can be run with `./gradlew run`: +The previous command creates a new Java application in a directory called `hello-world` featuring a Gradle build. You can run the application with `./gradlew run`: [source,bash] ---- @@ -22,26 +22,26 @@ $ ./gradlew run [main] INFO io.micronaut.runtime.Micronaut - Startup completed in 972ms. Server Running: http://localhost:28933 ---- -If you have created a Maven based project, use `./mvnw mn:run` instead. +If you have created a Maven-based project, use `./mvnw mn:run` instead. NOTE: For Windows the ./ before commands is not needed -By default the Micronaut HTTP server is configured to run on port 8080. See the section <> in the user guide for more options. +By default the Micronaut HTTP server is configured to run on port 8080. See the section <> for more options. -In order to create a service that responds to "Hello World" you first need a controller. The following is an example of a controller: +To create a service that responds to "Hello World" you first need a controller. The following is an example: snippet::io.micronaut.docs.server.intro.HelloController[tags="imports,class"] -<1> The class is defined as a controller with the link:{api}/io/micronaut/http/annotation/Controller.html[@Controller] annotation mapped to the path `/hello` -<2> The link:{api}/io/micronaut/http/annotation/Get.html[@Get] annotation is used to map the `index` method to all requests that use an HTTP `GET` -<3> A String "Hello World" is returned as the result +<1> The link:{api}/io/micronaut/http/annotation/Controller.html[@Controller] annotation defines the class as a controller mapped to the path `/hello` +<2> The link:{api}/io/micronaut/http/annotation/Get.html[@Get] annotation maps the `index` method to all requests that use an HTTP `GET` +<3> A String "Hello World" is returned as the response [%hardbreaks] -If you are using Java, place the previous file in `src/main/java/hello/world`. -If you are using Groovy, place the previous file in `src/main/groovy/hello/world`. -If you are using Kotlin, place the previous file in `src/main/kotlin/hello/world`. +If you use Java, place the previous file in `src/main/java/hello/world`. +If you use Groovy, place the previous file in `src/main/groovy/hello/world`. +If you use Kotlin, place the previous file in `src/main/kotlin/hello/world`. -If you start the application and send a request to the `/hello` URI then the text "Hello World" is returned: +If you start the application and send a `GET` request to the `/hello` URI, the text "Hello World" is returned: [source,bash] ---- diff --git a/src/main/docs/guide/quickStart/deployingApp.adoc b/src/main/docs/guide/quickStart/deployingApp.adoc index 5005aaf8ceb..6b9433fba62 100644 --- a/src/main/docs/guide/quickStart/deployingApp.adoc +++ b/src/main/docs/guide/quickStart/deployingApp.adoc @@ -1,4 +1,4 @@ -To deploy a Micronaut application you create a runnable JAR file by running `./gradlew assemble` or `./mvnw package`. +To deploy a Micronaut application you create an executable JAR file by running `./gradlew assemble` or `./mvnw package`. The constructed JAR file can then be executed with `java -jar`. For example: @@ -16,9 +16,9 @@ $ java -jar target/hello-world.jar if building with Maven. -The runnable JAR can be executed locally, deployed to a virtual machine or managed Cloud service that supports runnable JARs. +The executable JAR can be run locally, or deployed to a virtual machine or managed Cloud service that supports executable JARs. -To publish a layered application to a Docker container registry you can configure your Docker image name in `build.gradle` for Gradle: +To publish a layered application to a Docker container registry, configure your Docker image name in `build.gradle` for Gradle: [source,groovy] ---- @@ -49,7 +49,7 @@ For Maven, define the following plugin in your POM: ---- -Then invoke the `deploy` lifecycle phase specifying the packaging type to either `docker` or `docker-native`: +Then invoke the `deploy` lifecycle phase specifying the packaging type as either `docker` or `docker-native`: [source,bash] ---- diff --git a/src/main/docs/guide/quickStart/ideSetup.adoc b/src/main/docs/guide/quickStart/ideSetup.adoc index 49c6b7fe051..ede8a32d1e1 100644 --- a/src/main/docs/guide/quickStart/ideSetup.adoc +++ b/src/main/docs/guide/quickStart/ideSetup.adoc @@ -1,5 +1,5 @@ -The application created in the previous section contains a "main class" located in `src/main/java` that looks like the following: +The application created in the previous section contains a main class located in `src/main/java` that looks like the following: snippet::io.micronaut.docs.server.intro.Application[tags="imports,class"] -This is the class that is run when running the application via Gradle or via deployment. You can also run the main class directly within your IDE if it is configured correctly. +This is the class that is run when starting the application via Gradle/Maven or via deployment. You can also run the main class directly within your IDE. diff --git a/src/main/docs/guide/quickStart/ideSetup/eclipseSetup.adoc b/src/main/docs/guide/quickStart/ideSetup/eclipseSetup.adoc index 70adb4c9906..e408ce4f551 100644 --- a/src/main/docs/guide/quickStart/ideSetup/eclipseSetup.adoc +++ b/src/main/docs/guide/quickStart/ideSetup/eclipseSetup.adoc @@ -1,10 +1,10 @@ -If you wish to use Eclipse IDE, it is recommended you import your Micronaut project into Eclipse using either https://projects.eclipse.org/projects/tools.buildship[Gradle BuildShip] for Gradle or http://www.eclipse.org/m2e/[M2Eclipse] for Maven. +To use Eclipse IDE, it is recommended you import your Micronaut project into Eclipse using either https://projects.eclipse.org/projects/tools.buildship[Gradle BuildShip] for Gradle or http://www.eclipse.org/m2e/[M2Eclipse] for Maven. -NOTE: Micronaut requires Eclipse IDE 4.9 or above +NOTE: Micronaut requires Eclipse IDE 4.9 or higher === Eclipse and Gradle -Once you have setup Eclipse 4.9 or above with https://projects.eclipse.org/projects/tools.buildship[Gradle BuildShip] first run the `gradle eclipse` task from the root of your project then import the project by selecting `File -> Import` then choosing `Gradle -> Existing Gradle Project` and navigating to the root directory of your project (where the `build.gradle` is located). +Once you have set up Eclipse 4.9 or higher with https://projects.eclipse.org/projects/tools.buildship[Gradle BuildShip], first run the `gradle eclipse` task from the root of your project, then import the project by selecting `File -> Import` and choosing `Gradle -> Existing Gradle Project` and navigating to the root directory of your project (where the `build.gradle` file is located). === Eclipse and Maven @@ -13,6 +13,6 @@ For Eclipse 4.9 and above with Maven you need the following Eclipse plugins: * http://www.eclipse.org/m2e/[M2Eclipse for Maven] * https://github.com/jbosstools/m2e-apt[Maven integration with Eclipse JDT Annotation Processor Toolkit] -Once installed you need to import the project by selecting `File -> Import` then choosing `Maven -> Existing Maven Project` and navigating to the root directory of your project (where the `pom.xml` is located). +Once these are installed, import the project by selecting `File -> Import` and choosing `Maven -> Existing Maven Project` and navigating to the root directory of your project (where the `pom.xml` file is located). -You should then enable annotation processing by opening `Eclipse -> Preferences` and navigating to `Maven -> Annotation Processing` and selecting the option `Automatically configure JDT APT`. \ No newline at end of file +Then enable annotation processing by opening `Eclipse -> Preferences` and navigating to `Maven -> Annotation Processing` and selecting the option `Automatically configure JDT APT`. diff --git a/src/main/docs/guide/quickStart/ideSetup/ideaSetup.adoc b/src/main/docs/guide/quickStart/ideSetup/ideaSetup.adoc index 8ca8902ce90..a7ffd789eb9 100644 --- a/src/main/docs/guide/quickStart/ideSetup/ideaSetup.adoc +++ b/src/main/docs/guide/quickStart/ideSetup/ideaSetup.adoc @@ -1,7 +1,7 @@ -To import a Micronaut project into IntelliJ IDEA simply open the `build.gradle` or `pom.xml` file and follow the instructions to import the project. +To import a Micronaut project into IntelliJ IDEA, open the `build.gradle` or `pom.xml` file and follow the instructions to import the project. -For IntelliJ IDEA if you plan to use the IntelliJ compiler then you should enable annotation processing under the "Build, Execution, Deployment -> Compiler -> Annotation Processors" by ticking the "Enable annotation processing" checkbox: +For IntelliJ IDEA, if you plan to use the IntelliJ compiler, enable annotation processing under "Build, Execution, Deployment -> Compiler -> Annotation Processors" by ticking the "Enable annotation processing" checkbox: image::intellij-annotation-processors.png[Intellij Settings,1024,768] -Once you have enabled annotation processing in IntelliJ you can run the application and tests directly within the IDE without the need of an external build tool such as Gradle or Maven. \ No newline at end of file +Once you have enabled annotation processing in IntelliJ you can run the application and tests directly within the IDE without the need of an external build tool such as Gradle or Maven. diff --git a/src/main/docs/guide/quickStart/ideSetup/vsCodeSetup.adoc b/src/main/docs/guide/quickStart/ideSetup/vsCodeSetup.adoc index bec1e30c5c1..fda4996bb12 100644 --- a/src/main/docs/guide/quickStart/ideSetup/vsCodeSetup.adoc +++ b/src/main/docs/guide/quickStart/ideSetup/vsCodeSetup.adoc @@ -1,12 +1,12 @@ -Micronaut can be setup within Visual Studio Code. You will need to first install the The https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java Extension Pack]. +Micronaut can be set up within Visual Studio Code. First install the https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack[Java Extension Pack]. TIP: You can also optionally install https://marketplace.visualstudio.com/items?itemName=Pivotal.vscode-spring-boot[STS] to enable code completion for `application.yml`. -If you are using Gradle prior to opening the project in VSC you should run the following command from a terminal window: +If you use Gradle, prior to opening the project in VSC run the following command from a terminal window: [source,bash] ---- ./gradlew eclipse ---- -Once the extension pack is installed and if you have setup https://code.visualstudio.com/docs/setup/mac[terminal integration] just type `code .` in any project directory and the project will be automatically setup. \ No newline at end of file +Once the extension pack is installed and if you have setup https://code.visualstudio.com/docs/setup/mac[terminal integration] just type `code .` in any project directory and the project will be automatically setup. diff --git a/src/main/docs/guide/serverlessFunctions/awsLambda.adoc b/src/main/docs/guide/serverlessFunctions/awsLambda.adoc index d75636bf8ed..542e197018a 100644 --- a/src/main/docs/guide/serverlessFunctions/awsLambda.adoc +++ b/src/main/docs/guide/serverlessFunctions/awsLambda.adoc @@ -2,7 +2,7 @@ Support for AWS Lambda is implemented in the https://micronaut-projects.github.i ==== Simple Functions with AWS Lambda -You can implement AWS Request Handlers with Micronaut that implement directly the AWS Lambda SDK API. See the documentation on https://micronaut-projects.github.io/micronaut-aws/latest/guide/#requestHandlers[Micronaut Request Handlers] for more information. +You can implement AWS Request Handlers with Micronaut that directly implement the AWS Lambda SDK API. See the documentation on https://micronaut-projects.github.io/micronaut-aws/latest/guide/#requestHandlers[Micronaut Request Handlers] for more information. [TIP] .Using the CLI @@ -20,7 +20,7 @@ $ unzip example.zip -d example ==== HTTP Functions with AWS Lambda -You can deploy regular Micronaut applications that use ann:http.annotation.Controller[] etc. using Micronaut's support for AWS API Gateway. See the documentation on https://micronaut-projects.github.io/micronaut-aws/snapshot/guide/#apiProxy[AWS API Gateway Support] for more information. +You can deploy regular Micronaut applications that use ann:http.annotation.Controller[], etc. using Micronaut's support for AWS API Gateway. See the documentation on https://micronaut-projects.github.io/micronaut-aws/snapshot/guide/#apiProxy[AWS API Gateway Support] for more information. [TIP] .Using the CLI @@ -34,4 +34,4 @@ Or with Micronaut Launch $ curl https://launch.micronaut.io/example.zip\?features\=aws-lambda -o example.zip $ unzip example.zip -d example ---- -==== \ No newline at end of file +==== diff --git a/src/main/docs/guide/serverlessFunctions/azureFunction.adoc b/src/main/docs/guide/serverlessFunctions/azureFunction.adoc index f898a9fa5e0..0ced2436545 100644 --- a/src/main/docs/guide/serverlessFunctions/azureFunction.adoc +++ b/src/main/docs/guide/serverlessFunctions/azureFunction.adoc @@ -2,7 +2,7 @@ Support for Azure Function is implemented in the https://micronaut-projects.gith ==== Simple Functions with Azure Function -You can implement Azure Functions with Micronaut that implement directly the https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-java?tabs=consumption[Azure Function Java SDK]. See the documentation on https://micronaut-projects.github.io/micronaut-azure/1.0.x/guide/index.html#azureFunction[Azure Functions] for more information. +You can implement Azure Functions with Micronaut that directly implement the https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-java?tabs=consumption[Azure Function Java SDK]. See the documentation on https://micronaut-projects.github.io/micronaut-azure/1.0.x/guide/index.html#azureFunction[Azure Functions] for more information. [TIP] .Using the CLI diff --git a/src/main/docs/guide/serverlessFunctions/gcpCloudRun.adoc b/src/main/docs/guide/serverlessFunctions/gcpCloudRun.adoc index 71014770452..99b9bd967b0 100644 --- a/src/main/docs/guide/serverlessFunctions/gcpCloudRun.adoc +++ b/src/main/docs/guide/serverlessFunctions/gcpCloudRun.adoc @@ -14,21 +14,21 @@ $ unzip example.zip -d example ---- ==== -With JIB setup to deploy your application to Google Container Registry you can simple run: +With JIB setup to deploy your application to Google Container Registry, run: [source, bash] ---- $ ./gradlew jib ---- -You are now ready to deploy your application : +You are now ready to deploy your application: [source, bash] ---- $ gcloud run deploy --image gcr.io/[PROJECT ID]/example --platform=managed --allow-unauthenticated ---- -Where `[PROJECT ID]` is replaced for your project ID. You should be asked to specify a region and see output like the following: +Where `[PROJECT ID]` is your project ID. You will be asked to specify a region and will see output like the following: [source] ---- diff --git a/src/main/docs/guide/serverlessFunctions/gcpFunction.adoc b/src/main/docs/guide/serverlessFunctions/gcpFunction.adoc index 493b3e58a68..dccb4a5212b 100644 --- a/src/main/docs/guide/serverlessFunctions/gcpFunction.adoc +++ b/src/main/docs/guide/serverlessFunctions/gcpFunction.adoc @@ -2,7 +2,7 @@ Support for Google Cloud Function is implemented in the https://micronaut-projec ==== Simple Functions with Cloud Function -You can implement Cloud Functions with Micronaut that implement directly the https://github.com/GoogleCloudPlatform/functions-framework-java[Cloud Function Framework API]. See the documentation on https://micronaut-projects.github.io/micronaut-gcp/2.0.x/guide/#simpleFunctions[Simple Functions] for more information. +You can implement Cloud Functions with Micronaut that directly implement the https://github.com/GoogleCloudPlatform/functions-framework-java[Cloud Function Framework API]. See the documentation on https://micronaut-projects.github.io/micronaut-gcp/2.0.x/guide/#simpleFunctions[Simple Functions] for more information. [TIP] .Using the CLI @@ -34,4 +34,4 @@ Or with Micronaut Launch $ curl https://launch.micronaut.io/example.zip\?features\=google-cloud-function -o example.zip $ unzip example.zip -d example ---- -==== \ No newline at end of file +====