mirror of
https://github.com/jlengrand/quarkus.git
synced 2026-03-10 08:41:22 +00:00
Inline attribute project-name to Quarkus
Also fix some minor typos
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
= {project-name} - Test Extension
|
||||
= Quarkus - Test Extension
|
||||
|
||||
This is a non-released test extension that is used to validate the extension
|
||||
configuration and SPIs. As the extension SPI is expanded, this test
|
||||
|
||||
@@ -48,7 +48,6 @@
|
||||
<axle-version>${axle-client.version}</axle-version>
|
||||
<vertx-version>${vertx.version}</vertx-version>
|
||||
<restassured-version>${rest-assured.version}</restassured-version>
|
||||
<project-name>Quarkus</project-name>
|
||||
<!-- Project website home page -->
|
||||
<quarkus-home-url>${quarkus-home-url}</quarkus-home-url>
|
||||
<!-- Root URL of the GitHub organization -->
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
= How to Create Quarkus Documentation
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide describes the asciidoc format and conventions that the {project-name} has
|
||||
adopted.
|
||||
This guide describes the asciidoc format and conventions that Quarkus has adopted.
|
||||
|
||||
== References
|
||||
|
||||
@@ -22,7 +21,6 @@ complete list of externalized variables for use is given in the following table:
|
||||
[cols="<m,<m,<2",options="header"]
|
||||
|===
|
||||
|Property Name|Value|Description
|
||||
|\{project-name}|{project-name}|The official name of the project.
|
||||
|\{quarkus-version}|{quarkus-version}|The current version of the project.
|
||||
|\{quarkus-home-url}|{quarkus-home-url}| The location of the project home page.
|
||||
|\{quarkus-site-getting-started}|{quarkus-site-getting-started}| The location of the getting started page.
|
||||
@@ -30,13 +28,13 @@ complete list of externalized variables for use is given in the following table:
|
||||
|\{quarkus-site-extension-authors-guide}|{quarkus-site-extension-authors-guide}| The location of the extension authors guide page.
|
||||
|
||||
|\{quarkus-org-url}|{quarkus-org-url}| The location of the project github organization.
|
||||
|\{quarkus-base-url}|{quarkus-base-url}| {project-name} GitHub URL common base prefix.
|
||||
|\{quarkus-clone-url}|{quarkus-clone-url}| {project-name} URL for git clone referenced by the documentation.
|
||||
|\{quarkus-archive-url}|{quarkus-archive-url}| {project-name} URL to master source archive.
|
||||
|\{quarkus-blob-url}|{quarkus-blob-url}| {project-name} URL to master blob source tree; used for referencing source files.
|
||||
|\{quarkus-tree-url}|{quarkus-tree-url}| {project-name} URL to master source tree root; used for referencing directories.
|
||||
|\{quarkus-issues-url}|{quarkus-issues-url}| {project-name} URL to the issues page.
|
||||
|\{quarkus-images-url}|{quarkus-images-url}| {project-name} URL to set of container images delivered for Quarkus.
|
||||
|\{quarkus-base-url}|{quarkus-base-url}| Quarkus GitHub URL common base prefix.
|
||||
|\{quarkus-clone-url}|{quarkus-clone-url}| Quarkus URL for git clone referenced by the documentation.
|
||||
|\{quarkus-archive-url}|{quarkus-archive-url}| Quarkus URL to master source archive.
|
||||
|\{quarkus-blob-url}|{quarkus-blob-url}| Quarkus URL to master blob source tree; used for referencing source files.
|
||||
|\{quarkus-tree-url}|{quarkus-tree-url}| Quarkus URL to master source tree root; used for referencing directories.
|
||||
|\{quarkus-issues-url}|{quarkus-issues-url}| Quarkus URL to the issues page.
|
||||
|\{quarkus-images-url}|{quarkus-images-url}| Quarkus URL to set of container images delivered for Quarkus.
|
||||
|
||||
|\{quarkus-chat-url}|{quarkus-chat-url} | URL of our chat.
|
||||
|\{quarkus-mailing-list-subscription-email}|{quarkus-mailing-list-subscription-email} | Email used to subscribe to our mailing list.
|
||||
|
||||
@@ -35,7 +35,7 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
|
||||
== Enable Kubernetes support
|
||||
|
||||
{project-name} offers the ability to automatically generate Kubernetes resources based on sane defaults and user supplied configuration. The implementation that takes care
|
||||
Quarkus offers the ability to automatically generate Kubernetes resources based on sane defaults and user supplied configuration. The implementation that takes care
|
||||
of generating the actual Kubernetes resources is provided by https://github.com/ap4k/ap4k/[ap4k].
|
||||
|
||||
When we added the `kubernetes` extension to the command line invocation above, the following dependency was added to the `pom.xml`
|
||||
@@ -48,7 +48,7 @@ When we added the `kubernetes` extension to the command line invocation above, t
|
||||
</dependency>
|
||||
----
|
||||
|
||||
By adding this dependency, we now have the ability to configure the Kubernetes resource generation and application using the usual `application.properties` approach that {project-name} provides.
|
||||
By adding this dependency, we now have the ability to configure the Kubernetes resource generation and application using the usual `application.properties` approach that Quarkus provides.
|
||||
The configuration items that are available can be found in: `io.quarkus.kubernetes.deployment.KubernetesConfig` class.
|
||||
Furthermore, the items provided by `io.quarkus.deployment.ApplicationConfig` affect the Kubernetes resources.
|
||||
|
||||
|
||||
@@ -198,7 +198,7 @@ adding an additional extension to see what additional options have been added.
|
||||
|
||||
== Overriding properties at runtime
|
||||
|
||||
{project-name} does much of its configuration and bootstrap at build time.
|
||||
Quarkus does much of its configuration and bootstrap at build time.
|
||||
Most properties will then be read and set during the build time step.
|
||||
To change them, make sure to repackage your application.
|
||||
|
||||
@@ -338,7 +338,7 @@ change converters precedence and make your custom converter of higher priority t
|
||||
on the list.
|
||||
|
||||
By default, if no `@Priority` can be found on a converter, it's registered with a priority of 100
|
||||
and all {project-name} core converters are registered with a priority of 200, so depending on which
|
||||
and all Quarkus core converters are registered with a priority of 200, so depending on which
|
||||
converter you would like to replace, you need to set a higher value.
|
||||
|
||||
To demonstrate the idea let us implement a custom converter which will take precedence over
|
||||
@@ -377,7 +377,7 @@ NOTE: This new converter also needs to be listed in a service file, i.e. `META-I
|
||||
|
||||
== More info on how to configure
|
||||
|
||||
{project-name} relies on Eclipse MicroProfile and inherit its features.
|
||||
Quarkus relies on Eclipse MicroProfile and inherit its features.
|
||||
|
||||
There are converters that convert your property file content from `String` to typed Java types. See the list link:https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/asciidoc/converters.asciidoc[in the specification].
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
{project-name} allows different beans to interact using asynchronous messages, enforcing loose-coupling.
|
||||
Quarkus allows different beans to interact using asynchronous messages, enforcing loose-coupling.
|
||||
The messages are sent to _virtual addresses_.
|
||||
It offers 3 types of delivery mechanism:
|
||||
|
||||
@@ -33,7 +33,7 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
-Dextensions="vertx"
|
||||
----
|
||||
|
||||
If you have an already created project, the `vertx` extension can be added to an existing {project-name} project with
|
||||
If you have an already created project, the `vertx` extension can be added to an existing Quarkus project with
|
||||
the `add-extension` command:
|
||||
|
||||
[source]
|
||||
|
||||
@@ -15,40 +15,40 @@ include::./attributes.adoc[]
|
||||
:sectnums:
|
||||
:sectnumlevels: 4
|
||||
|
||||
{project-name} DI solution is based on the http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html[Contexts and Dependency Injection for Java 2.0, window="_blank"] specification.
|
||||
Quarkus DI solution is based on the http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html[Contexts and Dependency Injection for Java 2.0, window="_blank"] specification.
|
||||
However, it is not a full CDI implementation verified by the TCK.
|
||||
Only a subset of the CDI features is implemented - see also <<supported_features,the list of supported features>> and <<limitations,the list of limitations>>.
|
||||
|
||||
NOTE: Most of the existing CDI code should work just fine but there are some small differences which follow from the {project-name} architecture and goals.
|
||||
NOTE: Most of the existing CDI code should work just fine but there are some small differences which follow from the Quarkus architecture and goals.
|
||||
|
||||
[[bean_discovery]]
|
||||
== Bean Discovery
|
||||
|
||||
Bean discovery in CDI is a complex process which involves legacy deployment structures and accessibility requirements of the underlying module architecture.
|
||||
{project-name} is using a simplified bean discovery.
|
||||
Quarkus is using a simplified bean discovery.
|
||||
There is only one bean archive with `annotated` bean discovery mode and no visibility boundaries.
|
||||
|
||||
The bean archive is synthesized from:
|
||||
|
||||
* the application,
|
||||
* application dependencies that contain a `beans.xml` descriptor or a generated Jandex index (`META-INF/jandex.idx`),
|
||||
* and {project-name} integration code.
|
||||
* and Quarkus integration code.
|
||||
|
||||
Bean classes that don't have a http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#bean_defining_annotations[bean defining annotation, window="_blank"] are not discovered.
|
||||
This behavior is defined by CDI.
|
||||
But producer methods and fields and observer methods are discovered even if the declaring class is not annotated with a bean defining annotation (this behavior is different to what is defined in CDI).
|
||||
In fact, the declaring bean classes are considered annotated with `@Dependent`.
|
||||
|
||||
NOTE: {project-name} extension may declare additional discovery rules. For example `@Scheduled` business methods are registered even if the declaring class is not annotated with a bean defining annotation.
|
||||
NOTE: Quarkus extension may declare additional discovery rules. For example `@Scheduled` business methods are registered even if the declaring class is not annotated with a bean defining annotation.
|
||||
|
||||
|
||||
== Private Members
|
||||
|
||||
{project-name} is designed with Substrate VM in mind.
|
||||
Quarkus is designed with Substrate VM in mind.
|
||||
One of the limitations is the usage of https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#user-content-reflection[Reflection, window="_blank"].
|
||||
Substrate VM does support reflective calls but for a price of a bigger native executable.
|
||||
{project-name} must use reflection fallback to access private members.
|
||||
That's why {project-name} users are encouraged __not to use private members__ in their beans.
|
||||
Quarkus must use reflection fallback to access private members.
|
||||
That's why Quarkus users are encouraged __not to use private members__ in their beans.
|
||||
This involves injection fields, constructors and initializers, observer methods, producer methods and fields, disposers and interceptor methods.
|
||||
|
||||
You can use for example package-private modifiers:
|
||||
@@ -126,9 +126,9 @@ public class CounterBean {
|
||||
[[portable_extensions]]
|
||||
=== Portable Extensions
|
||||
|
||||
{project-name} incorporates build-time optimizations in order to provide instant startup and low memory footprint.
|
||||
Quarkus incorporates build-time optimizations in order to provide instant startup and low memory footprint.
|
||||
The downside of this approach is that CDI Portable Extensions cannot be supported.
|
||||
Nevertheless, most of the functionality can be achieved using {project-name} link:extension-authors-guide.html[extensions].
|
||||
Nevertheless, most of the functionality can be achieved using Quarkus link:extension-authors-guide.html[extensions].
|
||||
|
||||
=== Additional Bean Defining Annotations
|
||||
|
||||
@@ -182,7 +182,7 @@ NOTE: A bean registration that is a result of an `AdditionalBeanBuildItem` is re
|
||||
|
||||
Sometimes it is very useful to register a synthetic bean, i.e. a bean that doesn't need to have a corresponding java class.
|
||||
In CDI this could be achieved using `AfterBeanDiscovery.addBean()` methods.
|
||||
In {project-name} we produce a `BeanRegistrarBuildItem` and leverage the `io.quarkus.arc.processor.BeanConfigurator` API to build a synthetic bean definition.
|
||||
In Quarkus we produce a `BeanRegistrarBuildItem` and leverage the `io.quarkus.arc.processor.BeanConfigurator` API to build a synthetic bean definition.
|
||||
|
||||
[source,java]
|
||||
----
|
||||
|
||||
@@ -9,7 +9,7 @@ include::./attributes.adoc[]
|
||||
|
||||
== Installing the CLI
|
||||
|
||||
The {project-name} CLI is provided as a native binary for Linux and macOS or as a jar-file for
|
||||
The Quarkus CLI is provided as a native binary for Linux and macOS or as a jar-file for
|
||||
all operating systems.
|
||||
|
||||
=== Native CLI
|
||||
@@ -19,7 +19,7 @@ Download the binaries here:
|
||||
* https://coming-soon[Linux Binary] (coming soon)
|
||||
* https://coming-soon[macOS Binary] (coming soon)
|
||||
|
||||
We recommend that you create a specific {project-name} folder, eg '~/quarkus' and move the
|
||||
We recommend that you create a specific Quarkus folder, eg '~/quarkus' and move the
|
||||
binary there.
|
||||
Then in your shell profile (for Bash shell edit '~/.bash_profile'), export the 'QUARKUS_HOME'
|
||||
folder and add that to your 'PATH':
|
||||
@@ -33,7 +33,7 @@ Reload your terminal or do:
|
||||
[source,shell]
|
||||
source ~/.bash_profile
|
||||
|
||||
Now you can run the {project-name} CLI:
|
||||
Now you can run the Quarkus CLI:
|
||||
|
||||
[source,shell]
|
||||
$ quarkus --help
|
||||
@@ -43,7 +43,7 @@ This will display the help information with all the available commands.
|
||||
[source,shell]
|
||||
$ quarkus -i
|
||||
|
||||
This will start the {project-name} CLI in interactive mode.
|
||||
This will start the Quarkus CLI in interactive mode.
|
||||
|
||||
=== Jar CLI
|
||||
|
||||
@@ -87,7 +87,7 @@ $ quarkus create-project --help
|
||||
|
||||
== Dealing with extensions
|
||||
|
||||
The {project-name} CLI can obtain a list of the available extensions with:
|
||||
The Quarkus CLI can obtain a list of the available extensions with:
|
||||
|
||||
[source,shell]
|
||||
$ quarkus list-extensions
|
||||
@@ -100,7 +100,7 @@ $ quarkus list-extensions -n
|
||||
|
||||
== Adding extension(s)
|
||||
|
||||
The {project-name} CLI can add {project-name} extensions to your project with the 'add-extension'
|
||||
The Quarkus CLI can add Quarkus extensions to your project with the 'add-extension'
|
||||
command:
|
||||
|
||||
[source,shell]
|
||||
@@ -111,7 +111,7 @@ build file.
|
||||
|
||||
== Development mode
|
||||
|
||||
To start dev mode from the {project-name} CLI do:
|
||||
To start dev mode from the Quarkus CLI do:
|
||||
|
||||
[source,shell]
|
||||
$ quarkus dev /path/to/my/project
|
||||
|
||||
@@ -10,7 +10,7 @@ include::./attributes.adoc[]
|
||||
Many projects that use data require connections to a database.
|
||||
The main way of obtaining connections to a database is to use a datasource.
|
||||
|
||||
In {project-name}, the out of the box datasource and connection pooling implementation is https://agroal.github.io/[Agroal].
|
||||
In Quarkus, the out of the box datasource and connection pooling implementation is https://agroal.github.io/[Agroal].
|
||||
|
||||
This guide will explain how to:
|
||||
|
||||
@@ -164,7 +164,7 @@ More details can be found in the https://docs.microsoft.com/en-us/sql/connect/jd
|
||||
|
||||
== Injecting a Datasource
|
||||
|
||||
Because {project-name} uses CDI, injecting a datasource is very simple:
|
||||
Because Quarkus uses CDI, injecting a datasource is very simple:
|
||||
|
||||
[source,java,indent=0]
|
||||
--
|
||||
|
||||
@@ -533,7 +533,7 @@ public class LoggingProcessor {
|
||||
A configuration property name can be split into segments. For example, a property name like
|
||||
`quarkus.log.file.enable` can be split into the following segments:
|
||||
|
||||
* `quarkus` - a namespace claimed by {project-name} which is a prefix for all `@ConfigRoot` classes,
|
||||
* `quarkus` - a namespace claimed by Quarkus which is a prefix for all `@ConfigRoot` classes,
|
||||
* `log` - a name segment which corresponds to the `LogConfiguration` class annotated with `@ConfigRoot`,
|
||||
* `file` - a name segment which corresponds to the `file` field in this class,
|
||||
* `enabled` - a name segment which corresponds to `enable` field in `FileConfig` class annotated with `@ConfigGroup`.
|
||||
@@ -608,9 +608,9 @@ TODO: config integration
|
||||
|
||||
==== Extension Points
|
||||
|
||||
As a CDI based runtime, {project-name} extensions often make CDI beans available as part of the extension behavior.
|
||||
However, {project-name} DI solution does not support CDI Portable Extensions.
|
||||
Instead, {project-name} extensions can make use of various link:cdi-reference.html[Build Time Extension Points].
|
||||
As a CDI based runtime, Quarkus extensions often make CDI beans available as part of the extension behavior.
|
||||
However, Quarkus DI solution does not support CDI Portable Extensions.
|
||||
Instead, Quarkus extensions can make use of various link:cdi-reference.html[Build Time Extension Points].
|
||||
|
||||
=== Testing Extensions
|
||||
|
||||
@@ -724,7 +724,7 @@ public class PersistenceAndQuarkusConfigTest {
|
||||
}
|
||||
----
|
||||
|
||||
<1> This tells JUnit that the {project-name} deployment should fail with a specific exception
|
||||
<1> This tells JUnit that the Quarkus deployment should fail with a specific exception
|
||||
|
||||
|
||||
=== Native Executable Support
|
||||
@@ -756,20 +756,20 @@ A convenience feature that allows you to control most of the above features from
|
||||
|
||||
=== IDE support tips
|
||||
|
||||
==== Writing {project-name} extensions in Eclipse
|
||||
==== Writing Quarkus extensions in Eclipse
|
||||
|
||||
The only particular aspect of writing {project-name} extensions in Eclipse is that APT (Annotation Processing Tool) is required as part of extension builds, which means you need to:
|
||||
The only particular aspect of writing Quarkus extensions in Eclipse is that APT (Annotation Processing Tool) is required as part of extension builds, which means you need to:
|
||||
|
||||
- Install `m2e-apt` from https://marketplace.eclipse.org/content/m2e-apt
|
||||
- Define this property in your `pom.xml`: `<m2e.apt.activation>jdt_apt</m2e.apt.activation>`, although if you rely on `io.quarkus:quarkus-build-parent` you will get it for free.
|
||||
- If you have the `io.quarkus:quarkus-extension-processor` project open at the same time in your IDE (for example, if you have the {project-name} sources checked out and open in your IDE) you will need to close that project. Otherwise, Eclipse will not invoke the APT plugin that it contains.
|
||||
- If you have the `io.quarkus:quarkus-extension-processor` project open at the same time in your IDE (for example, if you have the Quarkus sources checked out and open in your IDE) you will need to close that project. Otherwise, Eclipse will not invoke the APT plugin that it contains.
|
||||
- If you just closed the extension processor project, be sure to do `Maven > Update Project` on the other projects in order for Eclipse to pick up the extension processor from the Maven repository.
|
||||
|
||||
=== Troubleshooting / Debugging Tips
|
||||
|
||||
==== Saving Application Generated Classes to Disk
|
||||
|
||||
The class augmentation step of {project-name} generates classes for various purposes. Sometimes you need to view these
|
||||
The class augmentation step of Quarkus generates classes for various purposes. Sometimes you need to view these
|
||||
classes/bytecode to debug or understand an issue. Classes that are related to application augmentation are currently held in
|
||||
memory in a runtime class loader. To have these classes written out to disk for inspection, specify the
|
||||
`quarkus.debug.generated-classes-dir` system property, for example:
|
||||
@@ -785,7 +785,7 @@ We have an extension that is used to test for regressions in the extension proce
|
||||
author will typically need to perform using the test-extension code to illustrate how the task could be done.
|
||||
|
||||
==== Features and Capabilities
|
||||
When you start a {project-name} instance, you will see a line like the one highlighted in this example:
|
||||
When you start a Quarkus instance, you will see a line like the one highlighted in this example:
|
||||
|
||||
.Example Startup Lines
|
||||
[source, bash]
|
||||
@@ -815,7 +815,7 @@ The features listed reflect the types of extensions that are installed. An exten
|
||||
|
||||
The feature name should map to a label in the extension's devtools/common/src/main/filtered/extensions.json entry so that
|
||||
the feature name displayed by the startup line matches a label that one can used to select the extension when creating a project
|
||||
using the {project-name} maven plugin as shown in this example taken from the Writing JSON REST Services guide where the "resteasy-jsonb" feature is referenced:
|
||||
using the Quarkus maven plugin as shown in this example taken from the Writing JSON REST Services guide where the "resteasy-jsonb" feature is referenced:
|
||||
|
||||
[source,shell,subs=attributes+]
|
||||
----
|
||||
@@ -986,7 +986,7 @@ You can use the `io.quarkus.arc.runtime.BeanContainer` interface to interact wit
|
||||
<5> Runtime template invokes the `IConfigConsumer#loadConfig(...)` method passing in the configuration objects with runtime information.
|
||||
|
||||
==== Manage Non-CDI Service
|
||||
A common purpose for an extension is to integrate a non-CDI aware service into the CDI based {project-name} runtime. Step 1 of this task is to load any configuration needed in a STATIC_INIT build step as we did in <<Parsing Config to Objects>>. Now we need to create an instance of the service using the configuration. Let's return to the `TestProcessor#parseServiceXmlConfig` method to see how this can be done.
|
||||
A common purpose for an extension is to integrate a non-CDI aware service into the CDI based Quarkus runtime. Step 1 of this task is to load any configuration needed in a STATIC_INIT build step as we did in <<Parsing Config to Objects>>. Now we need to create an instance of the service using the configuration. Let's return to the `TestProcessor#parseServiceXmlConfig` method to see how this can be done.
|
||||
|
||||
.Creating a Non-CDI Service
|
||||
[source,java]
|
||||
@@ -1065,7 +1065,7 @@ Now that you have recorded the creation of a service during the build phase, you
|
||||
<3> Call the runtime template to record the service start invocation.
|
||||
<4> Produce a `ServiceStartBuildItem` to indicate the startup of a service. See <<Startup and Shutdown Events>> for details.
|
||||
<5> Runtime template retrieves the service instance reference and calls its `startService` method.
|
||||
<6> Runtime template registers an invocation of the service instance `stopService` method with the {project-name} `ShutdownContext`.
|
||||
<6> Runtime template registers an invocation of the service instance `stopService` method with the Quarkus `ShutdownContext`.
|
||||
|
||||
The code for the `RuntimeXmlConfigService` can be viewed here:
|
||||
{quarkus-blob-url}/core/test-extension/runtime/src/main/java/io/quarkus/extest/runtime/RuntimeXmlConfigService.java[RuntimeXmlConfigService.java]
|
||||
@@ -1073,7 +1073,7 @@ The code for the `RuntimeXmlConfigService` can be viewed here:
|
||||
The testcase for validating that the `RuntimeXmlConfigService` has started can be found in the `testRuntimeXmlConfigService` test of `ConfiguredBeanTest` and `NativeImageIT`.
|
||||
|
||||
==== Startup and Shutdown Events
|
||||
The {project-name} container supports startup and shutdown lifecycle events to notify components of the container startup
|
||||
The Quarkus container supports startup and shutdown lifecycle events to notify components of the container startup
|
||||
and shutdown. There are CDI events fired that components can observe are illustrated in this example:
|
||||
|
||||
.Observing Container Startup
|
||||
@@ -1168,7 +1168,7 @@ Objects created during the build phase that are passed into the runtime need to
|
||||
... 36 more
|
||||
----
|
||||
|
||||
There is a `io.quarkus.runtime.ObjectSubstitution` interface that can be implemented to tell {project-name} how to handle such classes. An example implementation for the `DSAPublicKey` is shown here:
|
||||
There is a `io.quarkus.runtime.ObjectSubstitution` interface that can be implemented to tell Quarkus how to handle such classes. An example implementation for the `DSAPublicKey` is shown here:
|
||||
|
||||
.DSAPublicKeyObjectSubstitution Example
|
||||
[source,bash]
|
||||
|
||||
@@ -11,7 +11,6 @@ include::./attributes.adoc[]
|
||||
:numbered:
|
||||
:sectnums:
|
||||
:sectnumlevels: 4
|
||||
:project-name: Quarkus
|
||||
|
||||
== Native compilation
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ include::./attributes.adoc[]
|
||||
|
||||
https://flywaydb.org/[Flyway] is a popular database migration tool that is commonly used in JVM environments.
|
||||
|
||||
{project-name} provides first class support for using Flyway as will be explained in this guide.
|
||||
Quarkus provides first class support for using Flyway as will be explained in this guide.
|
||||
|
||||
== Setting up support for Flyway
|
||||
|
||||
@@ -43,7 +43,7 @@ In your `pom.xml`, add the following dependencies:
|
||||
</dependencies>
|
||||
--
|
||||
|
||||
Flyway support relies on the {project-name} default datasource config, you must add the default datasource properties
|
||||
Flyway support relies on the Quarkus default datasource config, you must add the default datasource properties
|
||||
to the `{config-file}` file in order to allow Flyway to manage the schema.
|
||||
Also, you can customize the Flyway behaviour by using the following properties:
|
||||
|
||||
@@ -126,7 +126,7 @@ INSERT INTO quarkus(id, name)
|
||||
VALUES (1, 'QUARKED');
|
||||
--
|
||||
|
||||
Now you can start your application and {project-name} will run the Flyway's migrate method according to your config:
|
||||
Now you can start your application and Quarkus will run the Flyway's migrate method according to your config:
|
||||
|
||||
[source,java]
|
||||
--
|
||||
@@ -150,7 +150,7 @@ public class MigrationService {
|
||||
In case you are interested in using the `Flyway` object directly, you can inject it as follows:
|
||||
|
||||
NOTE: If you enabled the `quarkus.flyway.migrate-at-start` property, by the time you use the Flyway instance,
|
||||
{project-name} will already have run the migrate operation
|
||||
Quarkus will already have run the migrate operation
|
||||
|
||||
[source,java]
|
||||
--
|
||||
|
||||
@@ -56,7 +56,7 @@ The solution is located in the `getting-started` directory.
|
||||
|
||||
== Bootstrapping the project
|
||||
|
||||
The easiest way to create a new {project-name} project is to open a terminal and run the following command:
|
||||
The easiest way to create a new Quarkus project is to open a terminal and run the following command:
|
||||
|
||||
[source,shell,subs=attributes+]
|
||||
----
|
||||
@@ -77,7 +77,7 @@ It generates:
|
||||
* the application configuration file
|
||||
|
||||
Once generated, look at the `pom.xml`.
|
||||
You will find the import of the Quarkus BOM, allowing you to omit the version on the different {project-name} dependencies.
|
||||
You will find the import of the Quarkus BOM, allowing you to omit the version on the different Quarkus dependencies.
|
||||
In addition, you can see the `quarkus-maven-plugin` responsible of the packaging of the application and also providing the development mode.
|
||||
|
||||
[source,xml,subs=attributes+]
|
||||
|
||||
@@ -8,7 +8,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
include::./attributes.adoc[]
|
||||
|
||||
// tag::repositories[]
|
||||
{project-name} Gradle plugin is not yet published to the https://plugins.gradle.org/[Gradle Plugin Portal],
|
||||
Quarkus Gradle plugin is not yet published to the https://plugins.gradle.org/[Gradle Plugin Portal],
|
||||
so you need to add the following at the top of your './settings.gradle' file:
|
||||
[source, groovy, subs=attributes+]
|
||||
----
|
||||
|
||||
@@ -11,8 +11,8 @@ include::./attributes.adoc[]
|
||||
|
||||
Configure your project as indicated in the link:gradle-config.html[Gradle configuration page].
|
||||
|
||||
At the moment there is no way of automatically generating a new project using the {project-name} Gradle plugin,
|
||||
luckily setting up a {project-name} project with Gradle is very simple. You only need to add the {project-name} Gradle plugin like this:
|
||||
At the moment there is no way of automatically generating a new project using the Quarkus Gradle plugin,
|
||||
luckily setting up a Quarkus project with Gradle is very simple. You only need to add the Quarkus Gradle plugin like this:
|
||||
|
||||
[source,groovy,subs=attributes+]
|
||||
----
|
||||
@@ -57,7 +57,7 @@ apply plugin: 'io.quarkus'
|
||||
[[project-creation]]
|
||||
== Creating a new project
|
||||
|
||||
For now we have to manually create a Gradle project file for {project-name}.
|
||||
For now we have to manually create a Gradle project file for Quarkus.
|
||||
Here is a complete sample file for a simple REST project:
|
||||
|
||||
[source,groovy,subs=attributes+]
|
||||
@@ -77,9 +77,9 @@ dependencies { // <2>
|
||||
}
|
||||
----
|
||||
|
||||
<1> The {project-name} plugin needs to be applied.
|
||||
<2> We include the {project-name} BOM using Gradle's link:https://docs.gradle.org/5.4.1/userguide/managing_transitive_dependencies.html#sec:bom_import[relevant syntax] and add RESTEasy dependency since we are developing a REST application similar to the getting started example.
|
||||
{project-name} also need this dependency for running tests, to provide this we use the `implementation` configuration.
|
||||
<1> The Quarkus plugin needs to be applied.
|
||||
<2> We include the Quarkus BOM using Gradle's link:https://docs.gradle.org/5.4.1/userguide/managing_transitive_dependencies.html#sec:bom_import[relevant syntax] and add RESTEasy dependency since we are developing a REST application similar to the getting started example.
|
||||
Quarkus also need this dependency for running tests, to provide this we use the `implementation` configuration.
|
||||
|
||||
Here's the same build script, using the Gradle Kotlin DSL:
|
||||
|
||||
@@ -102,7 +102,7 @@ dependencies {
|
||||
|
||||
== Enable Tests
|
||||
|
||||
{project-name} uses Junit5 and to enable it in Gradle we need to add a section to our build file:
|
||||
Quarkus uses Junit5 and to enable it in Gradle we need to add a section to our build file:
|
||||
|
||||
[source,groovy,subs=attributes+]
|
||||
----
|
||||
@@ -119,15 +119,15 @@ testCompile group: 'io.quarkus', name: 'quarkus-junit5', version: '{quarkus-vers
|
||||
testCompile group: 'io.rest-assured', name: 'rest-assured', version: '{restassured-version}'
|
||||
----
|
||||
|
||||
Note: {project-name} do not allow both link:getting-started-testing.html[QuarkusTests] and link:getting-started-testing.html#native-executable-testing[SubstrateTests] to run in the same test run.
|
||||
Note: Quarkus do not allow both link:getting-started-testing.html[QuarkusTests] and link:getting-started-testing.html#native-executable-testing[SubstrateTests] to run in the same test run.
|
||||
SubstrateTests should be seen as integration tests and moved to a different folder
|
||||
as recommended here:
|
||||
https://docs.gradle.org/current/userguide/java_testing.html#sec:configuring_java_integration_tests[Configuring integration tests].
|
||||
{project-name} supports running Substrate tests with Gradle, but the `buildNative` task is required to be completed first.
|
||||
Quarkus supports running Substrate tests with Gradle, but the `buildNative` task is required to be completed first.
|
||||
|
||||
== Dealing with extensions
|
||||
|
||||
From inside a {project-name} project, you can obtain a list of the available extensions with:
|
||||
From inside a Quarkus project, you can obtain a list of the available extensions with:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
@@ -138,7 +138,7 @@ Functionality to automatically add extensions to your Gradle project is not impl
|
||||
|
||||
== Development mode
|
||||
|
||||
{project-name} comes with a built-in development mode.
|
||||
Quarkus comes with a built-in development mode.
|
||||
Run your application with:
|
||||
|
||||
[source,shell]
|
||||
@@ -161,7 +161,7 @@ Hit `CTRL+C` to stop the application.
|
||||
|
||||
== Debugging
|
||||
|
||||
You can run a {project-name} application in debug mode using:
|
||||
You can run a Quarkus application in debug mode using:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
@@ -212,7 +212,7 @@ Open the project directory in VS Code. If you have installed the Java Extension
|
||||
|
||||
== Building a native executable
|
||||
|
||||
Native executables make {project-name} applications ideal for containers and serverless workloads.
|
||||
Native executables make Quarkus applications ideal for containers and serverless workloads.
|
||||
|
||||
Make sure to have `GRAALVM_HOME` configured and pointing to GraalVM version {graalvm-version}.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can utilize the MicroProfile
|
||||
This guide demonstrates how your Quarkus application can utilize the MicroProfile
|
||||
Health specification through the SmallRye Health extension.
|
||||
|
||||
MicroProfile Health allows applications to provide information about their state
|
||||
@@ -28,7 +28,7 @@ To complete this guide, you need:
|
||||
|
||||
In this guide, we build a simple REST application that exposes MicroProfile Health functionalities at
|
||||
the `/health` endpoint according to the specification. It will also provide several other REST
|
||||
endpoints to allow us to dynamically change the healthness of our {project-name} application.
|
||||
endpoints to allow us to dynamically change the healthness of our Quarkus application.
|
||||
|
||||
== Solution
|
||||
|
||||
@@ -52,14 +52,14 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
----
|
||||
|
||||
This command generates a Maven project, importing the `smallrye-health` extension
|
||||
which is an implementation of the MicroProfile Health specification used in {project-name}.
|
||||
which is an implementation of the MicroProfile Health specification used in Quarkus.
|
||||
|
||||
== Running the health check
|
||||
|
||||
Importing the `smallrye-health` extension directly exposes a single REST endpoint at
|
||||
the `/health` endpoint that can be used to run the health check procedures:
|
||||
|
||||
* start your {project-name} application with `mvn compile quarkus:dev`
|
||||
* start your Quarkus application with `mvn compile quarkus:dev`
|
||||
* access the `http://localhost:8080/health` endpoint using your browser or
|
||||
`curl http://localhost:8080/health`
|
||||
|
||||
@@ -104,11 +104,11 @@ interface which are defined as CDI beans with the `@Health` qualifier. `HealthCh
|
||||
a functional interface whose single method `call` returns a `HealthCheckResponse` object
|
||||
which can be easily constructed by the fluent builder API shown in the example.
|
||||
|
||||
As we have started our {project-name} application in dev mode simply repeat the request
|
||||
As we have started our Quarkus application in dev mode simply repeat the request
|
||||
to `http://localhost:8080/health` by refreshing your browser window or by using `curl http://localhost:8080/health`.
|
||||
The new health check procedure is now present in the `checks` array.
|
||||
|
||||
Congratulations! You've created your first {project-name} health check procedure. Let's
|
||||
Congratulations! You've created your first Quarkus health check procedure. Let's
|
||||
continue by exploring what else can be done with the MicroProfile Health specification.
|
||||
|
||||
== Adding user specific data to the health check response
|
||||
@@ -209,7 +209,7 @@ see in the `checks` array the newly added `Database connection health check` whi
|
||||
down and the error message explaining why it failed.
|
||||
|
||||
As we shouldn't leave this application with a health check in DOWN state and because we
|
||||
are running {project-name} dev mode you can add `database.up=true` in
|
||||
are running Quarkus dev mode you can add `database.up=true` in
|
||||
`src/main/resources/application.properties` and rerun the health check again --
|
||||
it should be up again.
|
||||
|
||||
@@ -218,9 +218,9 @@ it should be up again.
|
||||
MicroProfile Health provides a way for your application to distribute information
|
||||
about its healthness state to state whether or not it is able to function properly.
|
||||
|
||||
All that is needed to enable the MicroProfile Health features in {project-name} is:
|
||||
All that is needed to enable the MicroProfile Health features in Quarkus is:
|
||||
|
||||
* adding the `smallrye-health` {project-name} extension to your project using the `quarkus-maven-plugin`:
|
||||
* adding the `smallrye-health` Quarkus extension to your project using the `quarkus-maven-plugin`:
|
||||
|
||||
mvn quarkus:add-extension -Dextensions="health"
|
||||
|
||||
|
||||
@@ -9,12 +9,12 @@ include::./attributes.adoc[]
|
||||
:config-file: application.properties
|
||||
|
||||
Hibernate ORM is the de facto JPA implementation and offers you the full breath of an Object Relational Mapper.
|
||||
It works beautifully in {project-name}.
|
||||
It works beautifully in Quarkus.
|
||||
|
||||
== Setting up and configuring Hibernate ORM without `persistence.xml` (recommended)
|
||||
|
||||
More often than not, you need one _persistence unit_ with few configuration options.
|
||||
In {project-name}, you just need to:
|
||||
In Quarkus, you just need to:
|
||||
|
||||
* add your settings in `{config-file}`
|
||||
* annotate your entities with `@Entity` and friends
|
||||
@@ -61,7 +61,7 @@ quarkus.hibernate-orm.database.generation=drop-and-create
|
||||
Note that these configuration properties are not the same ones as in your typical Hibernate ORM configuration file: they might differ in names, casing and don't necessarily map 1:1 to each other.
|
||||
Please see below for the list of properties you can define.
|
||||
|
||||
An `EntityManagerFactory` will be created based on {project-name} `datasource` configuration as long as the Hibernate ORM extension is declared in your `pom.xml`.
|
||||
An `EntityManagerFactory` will be created based on Quarkus `datasource` configuration as long as the Hibernate ORM extension is declared in your `pom.xml`.
|
||||
The dialect will be selected based on the JDBC driver.
|
||||
|
||||
You can then happily inject your `EntityManager`:
|
||||
@@ -119,7 +119,7 @@ so at your application entry point boundaries like your REST endpoint controller
|
||||
|
||||
=== Properties to refine your Hibernate ORM configuration
|
||||
|
||||
There are optional properties useful to refine your `EntityManagerFactory` or guide guesses of {project-name}.
|
||||
There are optional properties useful to refine your `EntityManagerFactory` or guide guesses of Quarkus.
|
||||
|
||||
==== Dialect
|
||||
|
||||
@@ -195,7 +195,7 @@ Whether statistics collection is enabled.
|
||||
[NOTE]
|
||||
--
|
||||
Do not mix `persistence.xml` and `quarkus.hibernate-orm.*` properties in `{config-file}`.
|
||||
{project-name} will raise an exception.
|
||||
Quarkus will raise an exception.
|
||||
Make up your mind on which approach you want to use.
|
||||
--
|
||||
|
||||
@@ -336,7 +336,7 @@ public class Fruit {
|
||||
...
|
||||
--
|
||||
|
||||
That's all! Caching technology is already integrated and enabled by default in {project-name}, so it's enough to set which ones are safe to be cached.
|
||||
That's all! Caching technology is already integrated and enabled by default in Quarkus, so it's enough to set which ones are safe to be cached.
|
||||
|
||||
=== Tuning of Cache Regions
|
||||
|
||||
@@ -368,7 +368,7 @@ You can also provide duration values starting with a number. In this case, if th
|
||||
|
||||
=== Limitations of Caching
|
||||
|
||||
The caching technology provided within {project-name} is currently quite rudimentary and limited.
|
||||
The caching technology provided within Quarkus is currently quite rudimentary and limited.
|
||||
|
||||
The team thought it was better to have _some_ caching capability to start with, than having nothing; you can expect better caching solution to be integrated in future releases, and any help and feedback in this area is very welcome.
|
||||
|
||||
@@ -387,7 +387,7 @@ On top of immutable data, in certain contexts it might be acceptable to enable c
|
||||
This is however not recommended and should be done with extreme care, as it might
|
||||
produce unexpected and unforeseen effects on the data.
|
||||
|
||||
Rather than enabling caching on mutable data, ideally a better solution would be to use a clustered cache; however at this time {project-name} doesn't provide any such implementation: feel free to get in touch and let this need known so that the team can take this into account.
|
||||
Rather than enabling caching on mutable data, ideally a better solution would be to use a clustered cache; however at this time Quarkus doesn't provide any such implementation: feel free to get in touch and let this need known so that the team can take this into account.
|
||||
--
|
||||
|
||||
Finally, the second-level cache can be disabled globally by setting `hibernate.cache.use_second_level_cache` to `false`; this is a setting that needs to be specified in the `persistence.xml` configuration file.
|
||||
|
||||
@@ -10,7 +10,7 @@ include::./attributes.adoc[]
|
||||
|
||||
Hibernate ORM is the de facto JPA implementation and offers you the full breadth of an Object Relational Mapper.
|
||||
It makes complex mappings possible, but it does not make simple and common mappings trivial.
|
||||
Hibernate ORM with Panache focuses on making your entities trivial and fun to write in {project-name}.
|
||||
Hibernate ORM with Panache focuses on making your entities trivial and fun to write in Quarkus.
|
||||
|
||||
== First: an example
|
||||
|
||||
|
||||
@@ -8,14 +8,14 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
include::./attributes.adoc[]
|
||||
|
||||
Infinispan is an in memory data grid that allows running in a server outside of application processes. This extension
|
||||
provides functionality to allow the client that can connect to said server when running in {project-name}.
|
||||
provides functionality to allow the client that can connect to said server when running in Quarkus.
|
||||
|
||||
More information can be found about Infinispan at https://infinispan.org and the client/server at
|
||||
https://infinispan.org/docs/dev/user_guide/user_guide.html#client_server
|
||||
|
||||
== Configuration
|
||||
|
||||
Once you have your {project-name} project configured you can add the `infinispan-client` extension
|
||||
Once you have your Quarkus project configured you can add the `infinispan-client` extension
|
||||
to your project by running the following from the command line in your project base directory.
|
||||
|
||||
[source]
|
||||
@@ -103,7 +103,7 @@ The default serialization is done using a library based on protobuf. We need to
|
||||
buf schema and a marshaller for each user type(s).
|
||||
|
||||
NOTE: Annotation based proto stream marshalling is not yet supported in
|
||||
the {project-name} Infinispan client. This will be added soon, allowing you to only annotate your classes,
|
||||
the Quarkus Infinispan client. This will be added soon, allowing you to only annotate your classes,
|
||||
skipping the following steps.
|
||||
|
||||
NOTE: This version has an issue currently requiring the Query DSL module as a dependency when running in
|
||||
@@ -246,7 +246,7 @@ And you pass the marshaller by defining the following:
|
||||
----
|
||||
|
||||
NOTE: Annotation based proto stream marshalling is not yet supported in
|
||||
the {project-name} infinispan client.
|
||||
the Quarkus Infinispan client.
|
||||
|
||||
=== Providing your own Marshaller
|
||||
|
||||
@@ -270,7 +270,7 @@ Note that the Marshaller implementation must have a no arg constructor or static
|
||||
== Dependency Injection
|
||||
|
||||
As you saw above we support the user injecting Marshaller configuration. You can do the inverse with
|
||||
the infinispan client extension providing injection for `RemoteCacheManager` and `RemoteCache` objects.
|
||||
the Infinispan client extension providing injection for `RemoteCacheManager` and `RemoteCache` objects.
|
||||
There is one global `RemoteCacheManager` that takes all of the configuration
|
||||
parameters setup in the above sections.
|
||||
|
||||
@@ -319,15 +319,15 @@ You can do this by adding the following dependency to your project.
|
||||
With this added you can use Infinispan querying just as you would normally, nothing special required.
|
||||
You can read more about this at https://infinispan.org/docs/dev/user_guide/user_guide.html#query_dsl.
|
||||
|
||||
You can use either the Query DSL or the Ickle Query language with the {project-name} infinispan client
|
||||
You can use either the Query DSL or the Ickle Query language with the Quarkus Infinispan client
|
||||
extension.
|
||||
|
||||
== Counters
|
||||
|
||||
Infinispan also has a notion of counters and the {project-name} infinispan client supports them out of
|
||||
Infinispan also has a notion of counters and the Quarkus Infinispan client supports them out of
|
||||
the box.
|
||||
|
||||
The {project-name} infinispan client extension allows for Dependency Injection
|
||||
The Quarkus Infinispan client extension allows for Dependency Injection
|
||||
of the `CounterManager` directly. All you need to do is annotate your field, constructor or method
|
||||
and you get it with no fuss. You can then use counters as you would normally.
|
||||
|
||||
@@ -352,7 +352,7 @@ The first step is to configure the `hotrod-client.properties` file to point to y
|
||||
and/or keystore. This is further detailed at
|
||||
https://infinispan.org/docs/dev/user_guide/user_guide.html#hr_encryption.
|
||||
|
||||
The reason that {project-name} is different is that SubstrateVM does not come with security
|
||||
The reason that Quarkus is different is that SubstrateVM does not come with security
|
||||
services enabled. This is mentioned at
|
||||
https://github.com/oracle/graal/blob/master/substratevm/JCA-SECURITY-SERVICES.md. To
|
||||
do this you will need to set the `<enableAllSecurityServices>true</enableAllSecurityServices>` value
|
||||
@@ -391,7 +391,7 @@ for encryption to work properly.
|
||||
== Authentication
|
||||
|
||||
This chart illustrates what mechanisms have been verified to be working properly with
|
||||
the {project-name} Infinispan Client extension.
|
||||
the Quarkus Infinispan Client extension.
|
||||
|
||||
.Mechanisms
|
||||
|===
|
||||
@@ -425,5 +425,5 @@ However you need to configure these through the `hotrod-client.properties` file
|
||||
== Additional Features
|
||||
|
||||
The Infinispan Client has additional features that were not mentioned here. This means this
|
||||
feature was not tested in a {project-name} environment and they may or may not work. Please let us
|
||||
feature was not tested in a Quarkus environment and they may or may not work. Please let us
|
||||
know if you need these added!
|
||||
|
||||
@@ -9,7 +9,7 @@ include::./attributes.adoc[]
|
||||
:extension-name: Smallrye JWT
|
||||
:mp-jwt: MicroProfile JWT RBAC
|
||||
|
||||
This guide explains how your {project-name} application can utilize {mp-jwt} to provide
|
||||
This guide explains how your Quarkus application can utilize {mp-jwt} to provide
|
||||
secured access to the JAX-RS endpoints.
|
||||
|
||||
== Configuration
|
||||
@@ -134,7 +134,7 @@ public class TokenSecuredResource {
|
||||
}
|
||||
}
|
||||
----
|
||||
<1> Add a `RequestScoped` as {project-name} uses a default scoping of `ApplicationScoped` and this
|
||||
<1> Add a `RequestScoped` as Quarkus uses a default scoping of `ApplicationScoped` and this
|
||||
will produce undesirable behavior since JWT claims are naturally request scoped.
|
||||
<2> Here we inject the JsonWebToken interface, and extension of the java.security.Principal interface that provides access to the claims associated with the current authenticated token.
|
||||
<3> @PermitAll is a JSR 250 common security annotation that indicates that the given endpoint is accessible by any caller, authenticated or not.
|
||||
@@ -187,7 +187,7 @@ the response is consistent with that:
|
||||
* authScheme is null
|
||||
* hasJWT is false
|
||||
|
||||
Use Ctrl-C to stop the {project-name} server.
|
||||
Use Ctrl-C to stop the Quarkus server.
|
||||
|
||||
So now let's actually secure something. Take a look at the new endpoint method `helloRolesAllowed` in the following:
|
||||
|
||||
@@ -766,7 +766,7 @@ eyJraWQiOiJcL3ByaXZhdGVLZXkucGVtIiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiO
|
||||
|
||||
|
||||
== Finally, Secured Access to /secured/roles-allowed
|
||||
Now let's use this to make a secured request to the /secured/roles-allowed endpoint. Make sure you have the {project-name} server running using the `./mvnw compile quarkus:dev` command, and then run the following command, making sure to use your version of the generated JWT from the previous step:
|
||||
Now let's use this to make a secured request to the /secured/roles-allowed endpoint. Make sure you have the Quarkus server running using the `./mvnw compile quarkus:dev` command, and then run the following command, making sure to use your version of the generated JWT from the previous step:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can utilize MicroProfile Reactive Messaging to interact with Apache Kafka.
|
||||
This guide demonstrates how your Quarkus application can utilize MicroProfile Reactive Messaging to interact with Apache Kafka.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can utilize the Apache Kafka Streams API to implement stream processing applications based on Apache Kafka.
|
||||
This guide demonstrates how your Quarkus application can utilize the Apache Kafka Streams API to implement stream processing applications based on Apache Kafka.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
|
||||
@@ -7,15 +7,15 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can use Keycloak to protect your JAX-RS applications using bearer token
|
||||
This guide demonstrates how your Quarkus application can use Keycloak to protect your JAX-RS applications using bearer token
|
||||
authorization, where these tokens are issued by a Keycloak Server.
|
||||
|
||||
Bearer Token Authorization is the process of authorizing HTTP requests based on the existence and validity of a bearer token representing a subject and his access context, where the token provides valuable information to determine the subject of the call as well whether or not a HTTP resource can be accessed.
|
||||
|
||||
Keycloak is a OAuth 2.0 compliant Authorization Server, capable of issuing access tokens so that you can use them to access protected resources. We are not going
|
||||
to enter into the details on what OAuth 2.0 is and how it works but give you a guideline on how to use OAuth 2.0 in your JAX-RS applications using the {project-name} Keycloak Extension.
|
||||
to enter into the details on what OAuth 2.0 is and how it works but give you a guideline on how to use OAuth 2.0 in your JAX-RS applications using the Quarkus Keycloak Extension.
|
||||
|
||||
If you are already familiar with Keycloak, you'll notice that the extension is basically another adapter implementation but specific for {project-name} applications. Otherwise, you can find more information in https://keycloak.org/[Keycloak documentation].
|
||||
If you are already familiar with Keycloak, you'll notice that the extension is basically another adapter implementation but specific for Quarkus applications. Otherwise, you can find more information in https://keycloak.org/[Keycloak documentation].
|
||||
|
||||
== Prerequisites
|
||||
|
||||
@@ -68,7 +68,7 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
----
|
||||
|
||||
This command generates a Maven project, importing the `keycloak` extension
|
||||
which is an implementation of a Keycloak Adapter for {project-name} applications and provides all the necessary capabilities to integrate with a Keycloak Server and perform bearer token authorization.
|
||||
which is an implementation of a Keycloak Adapter for Quarkus applications and provides all the necessary capabilities to integrate with a Keycloak Server and perform bearer token authorization.
|
||||
|
||||
== Writing the application
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can use Kogito to add business automation
|
||||
This guide demonstrates how your Quarkus application can use Kogito to add business automation
|
||||
to power it up with business processes and rules.
|
||||
|
||||
Kogito is a next generation business automation toolkit that originates from well known Open Source projects
|
||||
|
||||
@@ -9,7 +9,7 @@ include::./attributes.adoc[]
|
||||
|
||||
https://kotlinlang.org/[Kotlin] is a very popular programming language that targets the JVM (amongst other environments). Kotlin has experienced a surge in popularity the last few years making it the most popular JVM language, except for Java of course.
|
||||
|
||||
{project-name} provides first class support for using Kotlin as will be explained in this guide.
|
||||
Quarkus provides first class support for using Kotlin as will be explained in this guide.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
@@ -171,11 +171,11 @@ we have specified that classes annotated with `javax.ws.rs.Path` should not be `
|
||||
If your application contains classes annotated with `javax.enterprise.context.ApplicationScoped`
|
||||
for example, then `<option>all-open:annotation=javax.enterprise.context.ApplicationScoped</option>` needs to be added as well. Same goes for any class that needs to have a dynamic proxy created at runtime.
|
||||
|
||||
Future versions of {project-name} will configure the Kotlin compiler plugin in a way that will make it unnecessary to alter this configuration.
|
||||
Future versions of Quarkus will configure the Kotlin compiler plugin in a way that will make it unnecessary to alter this configuration.
|
||||
|
||||
== Live reload
|
||||
|
||||
{project-name} provides support for live reloading changes made to source code. This support is also available to Kotlin, meaning that developers can update their Kotlin source
|
||||
Quarkus provides support for live reloading changes made to source code. This support is also available to Kotlin, meaning that developers can update their Kotlin source
|
||||
code and immediately see their changes reflected.
|
||||
|
||||
To see this feature in action, first execute: `./mvnw compile quarkus:dev`
|
||||
|
||||
@@ -69,7 +69,7 @@ Instructions to build the image and run the container are written in those Docke
|
||||
|
||||
== Dealing with extensions
|
||||
|
||||
From inside a {project-name} project, you can obtain a list of the available extensions with:
|
||||
From inside a Quarkus project, you can obtain a list of the available extensions with:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
@@ -106,7 +106,7 @@ $ mvn quarkus:add-extensions -Dextensions=jdbc,agroal,non-exist-ent
|
||||
|
||||
== Development mode
|
||||
|
||||
{project-name} comes with a built-in development mode.
|
||||
Quarkus comes with a built-in development mode.
|
||||
Run your application with:
|
||||
|
||||
[source,shell]
|
||||
@@ -164,7 +164,7 @@ app.
|
||||
|
||||
== Debugging
|
||||
|
||||
You can run a {project-name} application in debug mode using:
|
||||
You can run a Quarkus application in debug mode using:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
@@ -247,7 +247,7 @@ Now you should be able to execute `mvn quarkus-bootstrap:build-tree` on your pro
|
||||
|
||||
== Building a native executable
|
||||
|
||||
Native executables make {project-name} applications ideal for containers and serverless workloads.
|
||||
Native executables make Quarkus applications ideal for containers and serverless workloads.
|
||||
|
||||
Make sure to have `GRAALVM_HOME` configured and pointing to GraalVM version {graalvm-version}.
|
||||
Verify that your `pom.xml` has the proper `native` profile (see <<build-tool-maven>>).
|
||||
@@ -384,8 +384,8 @@ If you have not used <<project-creation,project scaffolding>>, add the following
|
||||
</profiles>
|
||||
----
|
||||
|
||||
<1> Optionally use a BOM file to omit the version of the different {project-name} dependencies.
|
||||
<2> Use the {project-name} Maven plugin that will hook into the build process
|
||||
<1> Optionally use a BOM file to omit the version of the different Quarkus dependencies.
|
||||
<2> Use the Quarkus Maven plugin that will hook into the build process
|
||||
<3> Use a native profile and plugin to activate GraalVM compilation
|
||||
<4> If you want to test your native executable with Integration Tests, add the following plugin configuration. Test names `*IT` and annotated `@SubstrateTest` will be run against the native executable. See the link:building-native-image-guide.html[Native executable guide] for more info.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can utilize the MicroProfile
|
||||
This guide demonstrates how your Quarkus application can utilize the MicroProfile
|
||||
Metrics specification through the SmallRye Metrics extension.
|
||||
|
||||
MicroProfile Metrics allows applications to gather various metrics and statistics that provide
|
||||
@@ -52,7 +52,7 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
-Dextensions="metrics"
|
||||
----
|
||||
|
||||
This command generates a Maven project, importing the `smallrye-metrics` extension which is an implementation of the MicroProfile Metrics specification used in {project-name}.
|
||||
This command generates a Maven project, importing the `smallrye-metrics` extension which is an implementation of the MicroProfile Metrics specification used in Quarkus.
|
||||
|
||||
== Writing the application
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ It goes without saying but it's better when you say it.
|
||||
|
||||
== How do we measure memory usage
|
||||
|
||||
When measuring the footprint of a {project-name} application, we measure https://en.wikipedia.org/wiki/Resident_set_size[Resident Set Size (RSS)]
|
||||
When measuring the footprint of a Quarkus application, we measure https://en.wikipedia.org/wiki/Resident_set_size[Resident Set Size (RSS)]
|
||||
and not the JVM heap size which is only a small part of the overall problem.
|
||||
The JVM not only allocates native memory for heap (`-Xms`, `-Xmx`) but also structures required by the jvm to run your application. Depending on the JVM implementation, the total memory allocated for an application will include, but not limited to:
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ include::./attributes.adoc[]
|
||||
|
||||
[quote]
|
||||
--
|
||||
{project-name} is a Cloud Native, Container First framework for writing Java applications.
|
||||
Quarkus is a Cloud Native, Container First framework for writing Java applications.
|
||||
--
|
||||
|
||||
Container First::
|
||||
@@ -40,7 +40,7 @@ All under one framework.
|
||||
== Scratch pad
|
||||
|
||||
|
||||
{project-name} believes in developer Joy.
|
||||
Quarkus believes in developer Joy.
|
||||
|
||||
|
||||
It unifies imperative and reactive.
|
||||
|
||||
@@ -12,7 +12,7 @@ The Reactive Postgres Client is a client for Postgres with a straightforward API
|
||||
|
||||
In this guide, you will learn how to implement a simple CRUD application exposing a RESTful API.
|
||||
|
||||
IMPORTANT: If you are not familiar with the {project-name} Vert.x extension, consider reading the link:using-vertx.html[Using Eclipse Vert.x] guide first.
|
||||
IMPORTANT: If you are not familiar with the Quarkus Vert.x extension, consider reading the link:using-vertx.html[Using Eclipse Vert.x] guide first.
|
||||
|
||||
The application shall manage fruit entities:
|
||||
|
||||
@@ -63,7 +63,7 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
-Dextensions="reactive-pg-client"
|
||||
----
|
||||
|
||||
If you have an already created project, the `reactive-pg-client` extension can be added to an existing {project-name} project with the `add-extension` command:
|
||||
If you have an already created project, the `reactive-pg-client` extension can be added to an existing Quarkus project with the `add-extension` command:
|
||||
|
||||
[source,shell]
|
||||
----
|
||||
@@ -181,7 +181,7 @@ It returns a `CompletionStage` and thus can be composed to execute queries seque
|
||||
----
|
||||
|
||||
NOTE: Wondering why we need to convert the result to `CompletableFuture` and block until the latest query is completed?
|
||||
This code is part of a `@PostConstruct` method and {project-name} invokes it synchronously.
|
||||
This code is part of a `@PostConstruct` method and Quarkus invokes it synchronously.
|
||||
As a consequence, returning prematurely could lead to serving requests while the database is not ready yet.
|
||||
|
||||
That's it!
|
||||
@@ -256,7 +256,7 @@ public CompletionStage<Response> get() {
|
||||
}
|
||||
----
|
||||
|
||||
Now start {project-name} in `dev` mode with:
|
||||
Now start Quarkus in `dev` mode with:
|
||||
|
||||
[source, shell]
|
||||
----
|
||||
|
||||
@@ -163,7 +163,7 @@ The `getByName` method gives our code the ability to query a country by name fro
|
||||
|
||||
The purpose of the annotations in the code above is the following:
|
||||
|
||||
* `@RegisterRestClient` allows {project-name} to know that this interface is meant to be available for
|
||||
* `@RegisterRestClient` allows Quarkus to know that this interface is meant to be available for
|
||||
CDI injection as a REST Client
|
||||
* `@Path`, `@GET` and `@PathParam` are the standard JAX-RS annotations used to define how to access the service
|
||||
* `@Produces` defines the expected content-type
|
||||
|
||||
@@ -220,9 +220,9 @@ quarkus.security.security-providers=SunRsaSign,SunJCE
|
||||
## Augmenting the Elytron Security Extension __Advanced Topic__
|
||||
[TIP]
|
||||
====
|
||||
Augmenting the elytron-security extension is an advanced topic that relies on writing a {project-name} extension and understanding all that entails. This only needs to be done if you have security stores and authentication mechanisms that are not supported by existing {project-name} extensions.
|
||||
Augmenting the elytron-security extension is an advanced topic that relies on writing a Quarkus extension and understanding all that entails. This only needs to be done if you have security stores and authentication mechanisms that are not supported by existing Quarkus extensions.
|
||||
====
|
||||
The elytron-security extension has support for overriding its Elytron `org.wildfly.security.auth.server.SecurityRealm` and the Undertow `io.undertow.security.idm.IdentityManager` used for authentication and authorization decisions. If your application needs to integrate with alternative identity stores and/or authentication mechanisms, then you can use this advanced feature to do so. In order to do this, one would write an {project-name} extension as described in link:extension-authors-guide.html[Extension Authors Guide] to produce `SecurityRealmBuildItem` and/or `IdentityManagerBuildItem` items as detailed in the following sections. The JWT RBAC extension described in the link:jwt-guide.html[JWT RBAC Security] is an example of an extension that makes use of these extension points.
|
||||
The elytron-security extension has support for overriding its Elytron `org.wildfly.security.auth.server.SecurityRealm` and the Undertow `io.undertow.security.idm.IdentityManager` used for authentication and authorization decisions. If your application needs to integrate with alternative identity stores and/or authentication mechanisms, then you can use this advanced feature to do so. In order to do this, one would write an Quarkus extension as described in link:extension-authors-guide.html[Extension Authors Guide] to produce `SecurityRealmBuildItem` and/or `IdentityManagerBuildItem` items as detailed in the following sections. The JWT RBAC extension described in the link:jwt-guide.html[JWT RBAC Security] is an example of an extension that makes use of these extension points.
|
||||
|
||||
### Adding a new Security Realm
|
||||
If one has an alternative store of identity and role information, it can be integrated by creating a `org.wildfly.security.auth.server.SecurityRealm` and producing a `io.quarkus.security.SecurityRealmBuildItem` from within the deployment module of a new extension. The deployment module would be responsible for exposing the necessary configuration information to allow users to enable and configure the security realm identity mappings.
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
This guide demonstrates how your {project-name} application can send emails using an SMTP server.
|
||||
This guide demonstrates how your Quarkus application can send emails using an SMTP server.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
@@ -22,7 +22,7 @@ To complete this guide, you need:
|
||||
|
||||
== Architecture
|
||||
|
||||
In this guide, we are going to see how you can send emails from a {project-name} application.
|
||||
In this guide, we are going to see how you can send emails from a Quarkus application.
|
||||
It covers simple emails, attachments, inlined attachments, the reactive and imperative APIs...
|
||||
|
||||
== Creating the Maven Project
|
||||
@@ -46,7 +46,7 @@ mvn quarkus:add-extensions -Dextensions="mailer"
|
||||
|
||||
== Configuring the mailer
|
||||
|
||||
The {project-name} mailer is using SMTP. In the `src/main/resources/application.properties` file, you need to configure the host, port, username, password as well as the other configuration aspect.
|
||||
The Quarkus mailer is using SMTP. In the `src/main/resources/application.properties` file, you need to configure the host, port, username, password as well as the other configuration aspect.
|
||||
Note that the password can also be configured using system properties and environment variables.
|
||||
|
||||
Here is an example using _sendgrid_:
|
||||
|
||||
@@ -7,9 +7,9 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
While you are encouraged to use CDI annotations for injection, {project-name} provides a compatibility layer for Spring dependency injection in the form of the `spring-di` extension.
|
||||
While you are encouraged to use CDI annotations for injection, Quarkus provides a compatibility layer for Spring dependency injection in the form of the `spring-di` extension.
|
||||
|
||||
This guide explains how your {project-name} application can leverage the well known Dependency Injection annotations included in the Spring Framework.
|
||||
This guide explains how your Quarkus application can leverage the well known Dependency Injection annotations included in the Spring Framework.
|
||||
|
||||
== Prerequisites
|
||||
|
||||
@@ -125,7 +125,7 @@ public class NoOpSingleStringFunction implements StringFunction {
|
||||
}
|
||||
----
|
||||
|
||||
{project-name} also provides support for injecting configuration values using Spring's `@Value` annotation.
|
||||
Quarkus also provides support for injecting configuration values using Spring's `@Value` annotation.
|
||||
To see that in action, first edit the `src/main/resources/application.properties` with the following content:
|
||||
|
||||
[source,java]
|
||||
|
||||
@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
|
||||
|
||||
include::./attributes.adoc[]
|
||||
|
||||
{project-name} comes with a toolchain enabling developers from live reload all the way down to deploying a Kubernetes application.
|
||||
Quarkus comes with a toolchain enabling developers from live reload all the way down to deploying a Kubernetes application.
|
||||
In this guide, we will explore:
|
||||
|
||||
* how to use link:maven-tooling.html[Maven] as a build tool
|
||||
@@ -22,7 +22,7 @@ In this guide, we will explore:
|
||||
[[build-tool]]
|
||||
== Choosing your build tool
|
||||
|
||||
{project-name} comes with a toolchain to help you at all development stages.
|
||||
Quarkus comes with a toolchain to help you at all development stages.
|
||||
You can use Maven or Gradle as build tool.
|
||||
And we offer a native CLI that is convenient to use (coming soon).
|
||||
|
||||
|
||||
@@ -11,8 +11,8 @@ Eclipse https://vertx.io[Vert.x] is a toolkit for building reactive applications
|
||||
It is designed to be lightweight and embeddable.
|
||||
Vert.x defines a reactive execution model and provides a large ecosystem.
|
||||
Quarkus integrates Vert.x to implement different reactive features, such as asynchronous message passing, and non-blocking HTTP client.
|
||||
Basically, {project-name} uses Vert.x as its reactive engine.
|
||||
While lots of reactive features from {project-name} don't _show_ Vert.x, it's used underneath.
|
||||
Basically, Quarkus uses Vert.x as its reactive engine.
|
||||
While lots of reactive features from Quarkus don't _show_ Vert.x, it's used underneath.
|
||||
But you can also access the managed Vert.x instance and benefit from the Vert.x ecosystem.
|
||||
|
||||
== Installing
|
||||
@@ -28,7 +28,7 @@ mvn io.quarkus:quarkus-maven-plugin:{quarkus-version}:create \
|
||||
-Dextensions="vertx"
|
||||
----
|
||||
|
||||
If you have an already created project, the `vertx` extension can be added to an existing {project-name} project with
|
||||
If you have an already created project, the `vertx` extension can be added to an existing Quarkus project with
|
||||
the `add-extension` command:
|
||||
|
||||
[source,shell]
|
||||
@@ -58,7 +58,7 @@ Once the extension has been added, you can access the _managed_ Vert.x instance
|
||||
If you are familiar with Vert.x, you know that Vert.x provides different API models.
|
||||
For instance _bare_ Vert.x uses callbacks, the RX Java 2 version uses `Single`, `Maybe`, `Completable`, `Observable` and `Flowable`.
|
||||
|
||||
{project-name} provides 3 Vert.x APIs:
|
||||
Quarkus provides 3 Vert.x APIs:
|
||||
|
||||
[options="header"]
|
||||
|===
|
||||
@@ -73,13 +73,13 @@ For instance _bare_ Vert.x uses callbacks, the RX Java 2 version uses `Single`,
|
||||
|
||||
|===
|
||||
|
||||
TIP: You may inject any of the 3 flavors of `Vertx` as well as the `EventBus` in your {project-name} application beans: `bare`, `Axle`, `RxJava2`.
|
||||
TIP: You may inject any of the 3 flavors of `Vertx` as well as the `EventBus` in your Quarkus application beans: `bare`, `Axle`, `RxJava2`.
|
||||
They are just shims and rely on a single _managed_ Vert.x instance.
|
||||
|
||||
You will pick one or the other depending on your use cases.
|
||||
|
||||
- `bare`: for advanced usage or if you have existing Vert.x code you want to reuse in your {project-name} application
|
||||
- `Axle`: works well with {project-name} and MicroProfile APIs (`CompletionStage` for single results and `Publisher` for streams)
|
||||
- `bare`: for advanced usage or if you have existing Vert.x code you want to reuse in your Quarkus application
|
||||
- `Axle`: works well with Quarkus and MicroProfile APIs (`CompletionStage` for single results and `Publisher` for streams)
|
||||
- `Rx Java 2`: when you need support for a wide range of data transformation operators on your streams
|
||||
|
||||
The following snippets illustrate the difference between these 3 APIs:
|
||||
@@ -117,7 +117,7 @@ vertx.fileSystem().readFile("lorem-ipsum.txt")
|
||||
|
||||
== Using Vert.x in Reactive JAX-RS resources
|
||||
|
||||
{project-name} web resources support asynchronous processing and streaming results over https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events[server-sent events].
|
||||
Quarkus web resources support asynchronous processing and streaming results over https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events[server-sent events].
|
||||
|
||||
=== Asynchronous processing
|
||||
|
||||
@@ -168,7 +168,7 @@ vertx.setTimer(10, l -> {
|
||||
----
|
||||
|
||||
That's it.
|
||||
Now start {project-name} in `dev` mode with:
|
||||
Now start Quarkus in `dev` mode with:
|
||||
|
||||
[source, shell]
|
||||
----
|
||||
@@ -184,7 +184,7 @@ Hello Quarkus! (10 ms)
|
||||
|
||||
=== Streaming using Server-Sent Events
|
||||
|
||||
{project-name} web resources that need to send content as https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events[server-sent events] must have a method:
|
||||
Quarkus web resources that need to send content as https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events[server-sent events] must have a method:
|
||||
|
||||
* declaring the `text/event-stream` response content type
|
||||
* returning a https://www.reactive-streams.org/[Reactive Streams] `Publisher` or an RX Java 2 `Observable` or `Flowable`
|
||||
@@ -299,7 +299,7 @@ Hello Quarkus! (Thu Mar 21 17:26:16 CET 2019)
|
||||
=== Using Vert.x JSON
|
||||
|
||||
Vert.x API heavily relies on JSON, namely the `io.vertx.core.json.JsonObject` and `io.vertx.core.json.JsonArray` types.
|
||||
They are both supported as {project-name} web resource request and response bodies.
|
||||
They are both supported as Quarkus web resource request and response bodies.
|
||||
|
||||
Consider these endpoints:
|
||||
|
||||
@@ -341,7 +341,7 @@ Needless to say, this works equally well when the JSON content is a request body
|
||||
|
||||
== Using Vert.x Clients
|
||||
|
||||
As you can inject a Vert.x instance, you can use Vert.x clients in a {project-name} application.
|
||||
As you can inject a Vert.x instance, you can use Vert.x clients in a Quarkus application.
|
||||
This section gives an example with the `WebClient`.
|
||||
|
||||
=== Picking the right dependency
|
||||
@@ -473,14 +473,14 @@ mvn package -Pnative
|
||||
|
||||
== Going further
|
||||
|
||||
There are many other facets of {project-name} using Vert.x underneath:
|
||||
There are many other facets of Quarkus using Vert.x underneath:
|
||||
|
||||
* The event bus is the connecting tissue of Vert.x applications.
|
||||
{project-name} integrates it so different beans can interact with asynchronous messages.
|
||||
Quarkus integrates it so different beans can interact with asynchronous messages.
|
||||
This part is covered in the link:async-message-passing.html[Async Message Passing documentation].
|
||||
|
||||
* Data streaming and Apache Kafka are a important parts of modern systems.
|
||||
{project-name} integrates data streaming using Reactive Messaging.
|
||||
Quarkus integrates data streaming using Reactive Messaging.
|
||||
More details on link:kafka-guide.html[Interacting with Kafka].
|
||||
|
||||
* Learn how to implement highly performant, low-overhead database applications on {project-name} with the link:reactive-postgres-client.html[Reactive Postgres Client].
|
||||
* Learn how to implement highly performant, low-overhead database applications on Quarkus with the link:reactive-postgres-client.html[Reactive Postgres Client].
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
= Read me
|
||||
:project-name: Quarkus
|
||||
:config-file: microprofile-config.properties
|
||||
:toc:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user