Using JBoss EAP XP 3.0.0
For Use with JBoss EAP XP 3.0.0
Abstract
Making open source more inclusive Copy linkLink copied to clipboard!
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
We appreciate your feedback on our documentation. To provide feedback, you can highlight the text in a document and add comments. Follow the steps in the procedure to learn about submitting feedback on Red Hat documentation.
Prerequisites
- Log in to the Red Hat Customer Portal.
- In the Red Hat Customer Portal, view the document in Multi-page HTML format.
Procedure
Click Feedback to see existing reader comments.
NoteThe feedback feature is enabled only in the Multi-page HTML format.
- Highlight the section of the document where you want to provide feedback.
In the prompt menu that displays near the text you selected, click Add Feedback.
A text box opens in the feedback section on the right side of the page.
Enter your feedback in the text box and click Submit.
You have created a documentation issue.
- To view the issue, click the issue tracker link in the feedback view.
Chapter 1. JBoss EAP XP for the latest MicroProfile capabilities Copy linkLink copied to clipboard!
1.1. About JBoss EAP XP Copy linkLink copied to clipboard!
The MicroProfile Expansion Pack (JBoss EAP XP) is available as a patch stream, which is provided using JBoss EAP XP manager.
JBoss EAP XP is subject to a separate support and life cycle policy. For more details, see the JBoss Enterprise Application Platform expansion pack Support and Life Cycle Policies page.
The JBoss EAP XP patch provides the following MicroProfile 4.0 components:
- MicroProfile Config
- MicroProfile Fault Tolerance
- MicroProfile Health
- MicroProfile JWT
- MicroProfile Metrics
- MicroProfile OpenAPI
- MicroProfile OpenTracing
- MicroProfile REST Client
- MicroProfile Reactive Messaging
The MicroProfile Reactive Messaging subsystem supports Red Hat AMQ Streams. This feature implements the MicroProfile Reactive Messaging 1.0 API and Red Hat provides the feature as a technology preview for JBoss EAP XP 3.0.0.
Red Hat tested Red Hat AMQ Streams 2021.Q2 on JBoss EAP. However, check the Red Hat JBoss Enterprise Application Platform supported configurations page for information about the latest Red Hat AMQ Streams version that has been tested on JBoss EAP XP 3.0.0.
1.2. JBoss EAP XP installation Copy linkLink copied to clipboard!
When you install JBoss EAP XP, make sure that the JBoss EAP XP patch is compatible with your version of JBoss EAP. The JBoss EAP XP 3.0.x patch is compatible with the JBoss EAP 7.4 release.
You can install JBoss EAP XP either through the XP manager and EAP archive or using the JBoss EAP XP OpenShift Container images. You cannot install JBoss EAP XP on top of EAP RPMs.
1.3. JBoss EAP XP manager Copy linkLink copied to clipboard!
JBoss EAP XP manager is an executable jar file that you can download from the Product Downloads page. Use JBoss EAP XP manager to apply the JBoss EAP XP patches from the JBoss EAP XP patch stream. The patches contain the MicroProfile 4.0 implementations and the bug fixes for these MicroProfile 4.0 implementations.
You can not manage the JBoss EAP XP patches using the management console.
If you run JBoss EAP XP manager without any arguments, or with the help command, you get a list of all the available commands with a description of what they do.
Run the manager with the help command to get more information about the arguments available.
Most of the JBoss EAP XP manager commands take a --jboss-home argument to point to the JBoss EAP XP server to manage the JBoss EAP XP patch stream. Specify the path to the server in the JBOSS_HOME environment variable if you want to omit this. --jboss-home takes precedence over the environment variable.
1.4. JBoss EAP XP manager 3.0 commands Copy linkLink copied to clipboard!
JBoss EAP XP manager 3.0 provides different commands for managing JBoss EAP XP patch streams and applying JBoss EAP 7.4.x base patches.
The following commands are provided:
patch-applyUse this command to apply patches to your JBoss EAP installation.
The
patch-applycommand is similar to thepatch applymanagement CLI command. Thepatch-applycommand accepts only those arguments that are required for applying patches using the tool. It uses the default values for otherpatch applymanagement CLI command arguments.You can use the
patch-applycommand to apply patches to any patch stream that is enabled on the server. You can also use the command to apply both the base server patches as well as the XP patches.Example of using the
patch-applycommand:java -jar jboss-eap-xp-manager.jar patch-apply --jboss-home=/PATH/TO/EAP --patch=/PATH/TO/PATCH/jboss-eap-7.3.4-patch.zip
$ java -jar jboss-eap-xp-manager.jar patch-apply --jboss-home=/PATH/TO/EAP --patch=/PATH/TO/PATCH/jboss-eap-7.3.4-patch.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow When you apply an XP patch, JBoss EAP XP manager 3.0 performs validation to prevent patch and patch stream mismatch. The following example illustrates incorrect combinations:
Trying to install JBoss EAP XP 2.0 patch on a server with XP 3.0 patch stream set up causes the following error:
java.lang.IllegalStateException: The JBoss EAP XP patch stream in the patch 'jboss-eap-xp-2.0' does not match the currently enabled JBoss EAP XP patch stream [jboss-eap-xp-3.0] at org.jboss.eap.util.xp.patch.stream.manager.ManagerPatchApplyAction.doExecute(ManagerPatchApplyAction.java:33) at org.jboss.eap.util.xp.patch.stream.manager.ManagerAction.execute(ManagerAction.java:40) at org.jboss.eap.util.xp.patch.stream.manager.ManagerMain.main(ManagerMain.java:50)
java.lang.IllegalStateException: The JBoss EAP XP patch stream in the patch 'jboss-eap-xp-2.0' does not match the currently enabled JBoss EAP XP patch stream [jboss-eap-xp-3.0] at org.jboss.eap.util.xp.patch.stream.manager.ManagerPatchApplyAction.doExecute(ManagerPatchApplyAction.java:33) at org.jboss.eap.util.xp.patch.stream.manager.ManagerAction.execute(ManagerAction.java:40) at org.jboss.eap.util.xp.patch.stream.manager.ManagerMain.main(ManagerMain.java:50)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Trying to install JBoss EAP XP 3.0 patch on a server that is not set up for JBoss EAP XP 3.0 patch stream causes the following error:
java.lang.IllegalStateException: You are attempting to install a patch for the 'jboss-eap-xp-3.0' JBoss EAP XP Patch Stream. However this patch stream is not yet set up in the JBoss EAP server. Run the 'setup' command to enable the patch stream. at org.jboss.eap.util.xp.patch.stream.manager.ManagerPatchApplyAction.doExecute(ManagerPatchApplyAction.java:29) at org.jboss.eap.util.xp.patch.stream.manager.ManagerAction.execute(ManagerAction.java:40) at org.jboss.eap.util.xp.patch.stream.manager.ManagerMain.main(ManagerMain.java:50)
java.lang.IllegalStateException: You are attempting to install a patch for the 'jboss-eap-xp-3.0' JBoss EAP XP Patch Stream. However this patch stream is not yet set up in the JBoss EAP server. Run the 'setup' command to enable the patch stream. at org.jboss.eap.util.xp.patch.stream.manager.ManagerPatchApplyAction.doExecute(ManagerPatchApplyAction.java:29) at org.jboss.eap.util.xp.patch.stream.manager.ManagerAction.execute(ManagerAction.java:40) at org.jboss.eap.util.xp.patch.stream.manager.ManagerMain.main(ManagerMain.java:50)Copy to Clipboard Copied! Toggle word wrap Toggle overflow In both the cases, no changes are made to the server.
removeUse this command to remove the JBoss EAP XP patch stream setup from the JBoss EAP server.
Example of using the
removecommandjava -jar jboss-eap-xp-manager.jar remove --jboss-home=/PATH/TO/EAP
$ java -jar jboss-eap-xp-manager.jar remove --jboss-home=/PATH/TO/EAPCopy to Clipboard Copied! Toggle word wrap Toggle overflow setupUse this command to set up a clean JBoss EAP server for the JBoss EAP XP patch stream.
When you use the
setupcommand, JBoss EAP XP manager performs the following actions:- Enables the JBoss EAP XP 3.0 patch stream.
-
Applies patches specified using
--base-patchand--xp-patchattributes. Copies the
standalone-microprofile.xmlandstandalone-microprofile-ha.xmlconfiguration files into the server configuration directory.If older configuration files are already installed, the new files are saved as timestamped copies in the target configuration directory, such as
standalone-microprofile-yyyyMMdd-HHmmss.xml.You can set the target directory using the
--jboss-config-directoryargument.
Example of using the
setupcommandjava -jar jboss-eap-xp-manager.jar setup --jboss-home=/PATH/TO/EAP
$ java -jar jboss-eap-xp-manager.jar setup --jboss-home=/PATH/TO/EAPCopy to Clipboard Copied! Toggle word wrap Toggle overflow statusUse this command to find the current status of your JBoss EAP XP server. The status command returns the following information:
- The status of the JBoss EAP XP stream.
- Any support policy changes due to being in the current state.
- The major version of JBoss EAP XP.
- Enabled patch streams and their cumulative patch IDs.
- The available JBoss EAP XP manager commands to change the state.
Example of using the
statuscommandjava -jar jboss-eap-xp-manager.jar status --jboss-home=/PATH/TO/EAP
$ java -jar jboss-eap-xp-manager.jar status --jboss-home=/PATH/TO/EAPCopy to Clipboard Copied! Toggle word wrap Toggle overflow upgradeUse this command to upgrade an old JBoss EAP XP patch stream to the latest patch stream in the JBoss EAP server.
When you use the
upgradecommand, JBoss EAP XP manager performs the following actions:- Creates a backup of the files enabling the old patch stream in the server.
- Enables the JBoss EAP XP 3.0 patch stream.
-
Applies patches specified using
--base-patchand--xp-patchattributes. -
Copies the
standalone-microprofile.xmlandstandalone-microprofile-ha.xmlconfiguration files into the server configuration directory. If older configuration files are already installed, the new files are saved as timestamped copies in the target configuration directory, such asstandalone-microprofile-yyyyMMdd-HHmmss.xml. If something goes wrong, JBoss EAP XP manager attempts to restore the previous patch stream from the backup it created.
You can set the target directory using the
--jboss-config-directoryargument
Example of using the
upgradecommand:java -jar jboss-eap-xp-manager.jar upgrade --jboss-home=/PATH/TO/EAP
$ java -jar jboss-eap-xp-manager.jar upgrade --jboss-home=/PATH/TO/EAPCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5. Installing JBoss EAP XP 3.0.0 on JBoss EAP 7.4.x Copy linkLink copied to clipboard!
Install JBoss EAP XP 3.0.0 on the JBoss EAP 7.4 base server.
Use JBoss EAP XP manager 3.0.0 to manage JBoss EAP XP 3.0.0 patch streams.
JBoss EAP XP 3.0.0 is certified with JBoss EAP 7.4.x.
Prerequisites
You have downloaded the following files from the Product Downloads page:
-
The
jboss-eap-xp-3.0.0-manager.jarfile (JBoss EAP XP manager 3.0) - JBoss EAP 7.4 server archive file
- JBoss EAP XP 3.0.0 patch
-
The
Procedure
- Extract the downloaded JBoss EAP 7.4 server archive file to the path of your JBoss EAP installation.
Set up JBoss EAP XP manager 3.0.0 to manage the JBoss EAP XP 3.0 patch stream by using the following command:
java -jar jboss-eap-xp-manager.jar setup --jboss-home=<path_to_eap>
$ java -jar jboss-eap-xp-manager.jar setup --jboss-home=<path_to_eap>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteYou can apply the JBoss EAP XP 3.0.0 patch at the same time. Include the path to the JBoss EAP XP 3.0.0 patch by using the
--xp-patchargument.Example:
java -jar jboss-eap-xp-manager.jar setup --jboss-home=<path_to_eap> --xp-patch <path_to_patch>jboss-eap-xp-3.0.0-patch.zip
$ java -jar jboss-eap-xp-manager.jar setup --jboss-home=<path_to_eap> --xp-patch <path_to_patch>jboss-eap-xp-3.0.0-patch.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow The server is now ready to manage the JBoss EAP XP 3.0.0 patch stream.
Optional: If you have not applied the JBoss EAP XP 3.0.0 patch to your JBoss EAP server by using the
--xp-patchargument, apply the JBoss EAP XP 3.0.0 patch by using the JBoss EAP XP manager 3.0.0patch-applycommand:java -jar jboss-eap-xp-manager.jar patch-apply --jboss-home=<path_to_eap> --patch=<path_to_patch>jboss-eap-xp-3.0.0-patch.zip
$ java -jar jboss-eap-xp-manager.jar patch-apply --jboss-home=<path_to_eap> --patch=<path_to_patch>jboss-eap-xp-3.0.0-patch.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow The
patch-applycommand is similar to thepatch applymanagement CLI command. You can also use thepatch applymanagement CLI command to apply the patch.
The JBoss EAP server is now ready to manage the JBoss EAP XP 3.0.0 patch stream as you patched the JBoss EAP server with the JBoss EAP XP 3.0.0 patch.
1.6. Uninstalling JBoss EAP XP Copy linkLink copied to clipboard!
Uninstalling JBoss EAP XP removes all the files related to enabling the JBoss EAP XP 3.0.0 patch stream and the MicroProfile 4.0 functionality. The uninstallation process does not affect anything in the base server patch stream or functionality.
The uninstallation process does not remove any configuration files, including the ones you added to the JBoss EAP XP patches when you enabled the JBoss EAP XP patch stream.
Procedure
Uninstall JBoss EAP XP 3.0.0 by issuing the following command:
java -jar jboss-eap-xp-manager.jar remove --jboss-home=/PATH/TO/EAP
$ java -jar jboss-eap-xp-manager.jar remove --jboss-home=/PATH/TO/EAPCopy to Clipboard Copied! Toggle word wrap Toggle overflow
To install MicroProfile 4.0 functionality again, run the setup command again to enable the patch stream, and then apply JBoss EAP XP patches to add the MicroProfile 4.0 modules.
1.7. Viewing the status of JBoss EAP XP Copy linkLink copied to clipboard!
You can view the following information with the status command:
- The status of the JBoss EAP XP stream.
- Any support policy changes due to being in the current state.
- The major version of JBoss EAP XP.
- Enabled patch streams and their cumulative patch ids.
- The available JBoss EAP XP manager commands to change the state.
JBoss EAP XP can be in one of the following states:
Not set up- JBoss EAP is clean and does not have JBoss EAP XP set up.
Set up- JBoss EAP has JBoss EAP XP set up. The version of the XP patch stream is not displays as the user can use CLI to determine it.
Inconsistent-
The files relating to the JBoss EAP XP are in an inconsistent state. This is an error condition and should not happen normally. If you encounter this error, remove the JBoss EAP XP manager as described in the Uninstalling JBoss EAP XP topic and install JBoss EAP XP again using the
setupcommand.
Procedure
View the status of JBoss EAP XP by issuing the following command:
java -jar jboss-eap-xp-manager.jar status --jboss-home=<path_to_eap>
$ java -jar jboss-eap-xp-manager.jar status --jboss-home=<path_to_eap>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional Resources
1.8. Rolling back JBoss EAP XP and JBoss EAP 7.4.x base patches Copy linkLink copied to clipboard!
You can roll back a previously applied JBoss EAP XP patch or JBoss EAP 7.4.x base patch using the management CLI.
Chapter 2. Understand MicroProfile Copy linkLink copied to clipboard!
2.1. MicroProfile Config Copy linkLink copied to clipboard!
2.1.1. MicroProfile Config in JBoss EAP Copy linkLink copied to clipboard!
Configuration data can change dynamically and applications need to be able to access the latest configuration information without restarting the server.
MicroProfile Config provides portable externalization of configuration data. This means, you can configure applications and microservices to run in multiple environments without modification or repackaging.
MicroProfile Config functionality is implemented in JBoss EAP using the SmallRye Config component and is provided by the microprofile-config-smallrye subsystem.
MicroProfile Config is only supported in JBoss EAP XP. It is not supported in JBoss EAP.
If you are adding your own Config implementations, you need to use the methods in the latest version of the Config interface.
Additional Resources
2.1.2. MicroProfile Config sources supported in MicroProfile Config Copy linkLink copied to clipboard!
MicroProfile Config configuration properties can come from different locations and can be in different formats. These properties are provided by ConfigSources. ConfigSources are implementations of the org.eclipse.microprofile.config.spi.ConfigSource interface.
The MicroProfile Config specification provides the following default ConfigSource implementations for retrieving configuration values:
-
System.getProperties(). -
System.getenv(). -
All
META-INF/microprofile-config.propertiesfiles on the class path.
The microprofile-config-smallrye subsystem supports additional types of ConfigSource resources for retrieving configuration values. You can also retrieve the configuration values from the following resources:
-
Properties in a
microprofile-config-smallrye/config-sourcemanagement resource - Files in a directory
-
ConfigSourceclass -
ConfigSourceProviderclass
Additional Resources
2.2. MicroProfile Fault Tolerance Copy linkLink copied to clipboard!
2.2.1. About MicroProfile Fault Tolerance specification Copy linkLink copied to clipboard!
The MicroProfile Fault Tolerance specification defines strategies to deal with errors inherent in distributed microservices.
The MicroProfile Fault Tolerance specification defines the following strategies to handle errors:
- Timeout
- Define the amount of time within which an execution must finish. Defining a timeout prevents waiting for an execution indefinitely.
- Retry
- Define the criteria for retrying a failed execution.
- Fallback
- Provide an alternative in the case of a failed execution.
- CircuitBreaker
- Define the number of failed execution attempts before temporarily stopping. You can define the length of the delay before resuming execution.
- Bulkhead
- Isolate failures in part of the system so that the rest of the system can still function.
- Asynchronous
- Execute client request in a separate thread.
Additional Resources
2.2.2. MicroProfile Fault Tolerance in JBoss EAP Copy linkLink copied to clipboard!
The microprofile-fault-tolerance-smallrye subsystem provides support for MicroProfile Fault Tolerance in JBoss EAP. The subsystem is available only in the JBoss EAP XP stream.
The microprofile-fault-tolerance-smallrye subsystem provides the following annotations for interceptor bindings:
-
@Timeout -
@Retry -
@Fallback -
@CircuitBreaker -
@Bulkhead -
@Asynchronous
You can bind these annotations at the class level or at the method level. An annotation bound to a class applies to all of the business methods of that class.
The following rules apply to binding interceptors:
If a component class declares or inherits a class-level interceptor binding, the following restrictions apply:
- The class must not be declared final.
- The class must not contain any static, private, or final methods.
- If a non-static, non-private method of a component class declares a method level interceptor binding, neither the method nor the component class may be declared final.
Fault tolerance operations have the following restrictions:
- Fault tolerance interceptor bindings must be applied to a bean class or bean class method.
- When invoked, the invocation must be the business method invocation as defined in the Jakarta Contexts and Dependency Injection specification.
An operation is not considered fault tolerant if both of the following conditions are true:
- The method itself is not bound to any fault tolerance interceptor.
- The class containing the method is not bound to any fault tolerance interceptor.
The microprofile-fault-tolerance-smallrye subsystem provides the following configuration options, in addition to the configuration options provided by MicroProfile Fault Tolerance:
-
io.smallrye.faulttolerance.globalThreadPoolSize -
io.smallrye.faulttolerance.timeoutExecutorThreads
Additional Resources
2.3. MicroProfile Health Copy linkLink copied to clipboard!
2.3.1. MicroProfile Health in JBoss EAP Copy linkLink copied to clipboard!
JBoss EAP includes the SmallRye Health component, which you can use to determine whether the JBoss EAP instance is responding as expected. This capability is enabled by default.
MicroProfile Health is only available when running JBoss EAP as a standalone server.
The MicroProfile Health specification defines the following health checks:
- Readiness
-
Determines whether an application is ready to process requests. The annotation
@Readinessprovides this health check. - Liveness
-
Determines whether an application is running. The annotation
@Livenessprovides this health check.
The @Health annotation was removed in MicroProfile Health 3.0.
MicroProfile Health 3.0 has the following breaking changes:
-
Pruning of
@Healthqualifier -
Renaming of the HealthCheckResponse
stateparameter tostatusto fix deserialization issues. This has also resulted in renaming of the corresponding methods.
For more information about the breaking changes in MicroProfile Health 3.0, see Release Notes for MicroProfile Health 3.0.
The :empty-readiness-checks-status and the :empty-liveness-checks-status management attributes specify the global status when no readiness or liveness probes are defined.
2.4. MicroProfile JWT Copy linkLink copied to clipboard!
2.4.1. MicroProfile JWT integration in JBoss EAP Copy linkLink copied to clipboard!
The subsystem microprofile-jwt-smallrye provides MicroProfile JWT integration in JBoss EAP.
The following functionalities are provided by the microprofile-jwt-smallrye subsystem:
- Detecting deployments that use MicroProfile JWT security.
- Activating support for MicroProfile JWT.
The subsystem contains no configurable attributes or resources.
In addition to the microprofile-jwt-smallrye subsystem, the org.eclipse.microprofile.jwt.auth.api module provides MicroProfile JWT integration in JBoss EAP.
Additional Resources
2.4.2. Differences between a traditional deployment and an MicroProfile JWT deployment Copy linkLink copied to clipboard!
MicroProfile JWT deployments do not depend on managed SecurityDomain resources like traditional JBoss EAP deployments. Instead, a virtual SecurityDomain is created and used across the MicroProfile JWT deployment.
As the MicroProfile JWT deployment is configured entirely within the MicroProfile Config properties and the microprofile-jwt-smallrye subsystem, the virtual SecurityDomain does not need any other managed configuration for the deployment.
2.4.3. MicroProfile JWT activation in JBoss EAP Copy linkLink copied to clipboard!
MicroProfile JWT is activated for applications based on the presence of an auth-method in the application.
The MicroProfile JWT integration is activated for an application in the following way:
-
As part of the deployment process, JBoss EAP scans the application archive for the presence of an
auth-method. -
If an
auth-methodis present and defined asMP-JWT, the MicroProfile JWT integration is activated.
The auth-method can be specified in either or both of the following files:
-
the file containing the class that extends
javax.ws.rs.core.Application, annotated with the@LoginConfig -
the
web.xmlconfiguration file
If auth-method is defined both in a class, using annotation, and in the web.xml configuration file, the definition in web.xml configuration file is used.
2.4.4. Limitations of MicroProfile JWT in JBoss EAP Copy linkLink copied to clipboard!
The MicroProfile JWT implementation in JBoss EAP has certain limitations.
The following limitations of MicroProfile JWT implementation exist in JBoss EAP:
-
The MicroProfile JWT implementation parses only the first key from the JSON Web Key Set (JWKS) supplied in the
mp.jwt.verify.publickeyproperty. Therefore, if a token claims to be signed by the second key or any key after the second key, the token fails verification and the request containing the token is not authorized. - Base64 encoding of JWKS is not supported.
In both cases, a clear text JWKS can be referenced instead of using the mp.jwt.verify.publickey.location config property.
2.5. MicroProfile Metrics Copy linkLink copied to clipboard!
2.5.1. MicroProfile Metrics in JBoss EAP Copy linkLink copied to clipboard!
JBoss EAP includes the SmallRye Metrics component. The SmallRye Metrics component provides the MicroProfile Metrics functionality using the microprofile-metrics-smallrye subsystem.
The microprofile-metrics-smallrye subsystem provides monitoring data for the JBoss EAP instance. The subsystem is enabled by default.
The microprofile-metrics-smallrye subsystem is only enabled in standalone configurations.
Additional Resources
2.6. MicroProfile OpenAPI Copy linkLink copied to clipboard!
2.6.1. MicroProfile OpenAPI in JBoss EAP Copy linkLink copied to clipboard!
MicroProfile OpenAPI is integrated in JBoss EAP using the microprofile-openapi-smallrye subsystem.
The MicroProfile OpenAPI specification defines an HTTP endpoint that serves an OpenAPI 3.0 document. The OpenAPI 3.0 document describes the REST services for the host. The OpenAPI endpoint is registered using the configured path, for example http://localhost:8080/openapi, local to the root of the host associated with a deployment.
Currently, the OpenAPI endpoint for a virtual host can only document a single deployment. To use OpenAPI with multiple deployments registered with different context paths on the same virtual host, each deployment must use a distinct endpoint path.
The OpenAPI endpoint returns a YAML document by default. You can also request a JSON document using an Accept HTTP header, or a format query parameter.
If the Undertow server or host of a given application defines an HTTPS listener then the OpenAPI document is also available using HTTPS. For example, an endpoint for HTTPS is https://localhost:8443/openapi.
2.7. MicroProfile OpenTracing Copy linkLink copied to clipboard!
2.7.1. MicroProfile OpenTracing Copy linkLink copied to clipboard!
The ability to trace requests across service boundaries is important, especially in a microservices environment where a request can flow through multiple services during its life cycle.
The MicroProfile OpenTracing specification defines behaviors and an API for accessing an OpenTracing compliant Tracer interface within a CDI-bean application. The Tracer interface automatically traces JAX-RS applications.
The behaviors specify how OpenTracing Spans are created automatically for incoming and outgoing requests. The API defines how to explicitly disable or enable tracing for given endpoints.
Additional Resources
- For more information about MicroProfile OpenTracing specification, see MicroProfile OpenTracing documentation.
-
For more information about the
Tracerinterface, seeTracerjavadoc.
2.7.2. MicroProfile OpenTracing in JBoss EAP Copy linkLink copied to clipboard!
You can use the microprofile-opentracing-smallrye subsystem to configure the distributed tracing of Jakarta EE applications. This subsystem uses the SmallRye OpenTracing component to provide the MicroProfile OpenTracing functionality for JBoss EAP.
MicroProfile OpenTracing 2.0 supports tracing requests for applications. You can configure the default Jaeger Java Client tracer, plus a set of instrumentation libraries for components commonly used in Jakarta EE, using JBoss EAP management API with the management CLI or the management console.
Each individual WAR deployed to the JBoss EAP server automatically has its own Tracer instance. Each WAR within an EAR is treated as an individual WAR, and each has its own Tracer instance. By default, the service name used with the Jaeger Client is derived from the deployment’s name, which is usually the WAR file name.
Within the microprofile-opentracing-smallrye subsystem, you can configure the Jaeger Java Client by setting system properties or environment variables.
Configuring the Jeager Client tracer using system properties and environment variables is provided as a Technology Preview. The system properties and environment variables affiliated with the Jeager Client tracer might change and become incompatible with each other in future releases.
By default, the probabilistic sampling strategy of the Jaeger Client for Java is set to 0.001, meaning that only approximately one in one thousand traces are sampled. To sample every request, set the system properties JAEGER_SAMPLER_TYPE to const and JAEGER_SAMPLER_PARAM to 1.
Additional Resources
- For more information about SmallRye OpenTracing functionality, see the SmallRye OpenTracing component.
- For more information about the default tracer, see the Jaeger Java Client.
-
For more information about the
Tracerinterface, seeTracerjavadoc. - For more information about overriding the default tracer and tracing Jakarta Contexts and Dependency Injection beans, see Using Eclipse MicroProfile OpenTracing to Trace Requests in the Development Guide.
- For more information about configuring the Jaeger Client, see the Jaeger documentation.
- For more information about valid system properties, see Configuration via Environment in the Jaeger documentation.
2.8. MicroProfile REST Client Copy linkLink copied to clipboard!
2.8.1. MicroProfile REST client Copy linkLink copied to clipboard!
JBoss EAP XP 3.0.0 supports the MicroProfile REST client 2.0 that builds on Jakarta RESTful Web Services 2.1.6 client APIs to provide a type-safe approach to invoke RESTful services over HTTP. The MicroProfile Type Safe REST clients are defined as Java interfaces. With the MicroProfile REST clients, you can write client applications with executable code.
Use the MicroProfile REST client to avail the following capabilities:
- An intuitive syntax
- Programmatic registration of providers
- Declarative registration of providers
- Declarative specification of headers
- Propagation of headers on the server
-
ResponseExceptionMapper - Jakarta Contexts and Dependency Injection integration
- Access to server-sent events (SSE)
Additional resources
- A comparison between MicroProfile REST client and Jakarta RESTful Web Services syntaxes
- Programmatic registration of providers in MicroProfile REST client
- Declarative registration of providers in MicroProfile REST client
- Declarative specification of headers in MicroProfile REST client
- Propagation of headers on the server in MicroProfile REST client
- ResponseExceptionMapper in MicroProfile REST client
- Context dependency injection with MicroProfile REST client
Chapter 3. Administer MicroProfile in JBoss EAP Copy linkLink copied to clipboard!
3.1. MicroProfile OpenTracing administration Copy linkLink copied to clipboard!
3.1.1. Enabling MicroProfile Open Tracing Copy linkLink copied to clipboard!
Use the following management CLI commands to enable the MicroProfile Open Tracing feature globally for the server instance by adding the subsystem to the server configuration.
Procedure
Enable the
microprofile-opentracing-smallryesubsystem using the following management command:/subsystem=microprofile-opentracing-smallrye:add()
/subsystem=microprofile-opentracing-smallrye:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server for the changes to take effect.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.2. Removing the microprofile-opentracing-smallrye subsystem Copy linkLink copied to clipboard!
The microprofile-opentracing-smallrye subsystem is included in the default JBoss EAP 7.4 configuration. This subsystem provides MicroProfile OpenTracing functionality for JBoss EAP 7.4. If you experience system memory or performance degradation with MicroProfile OpenTracing enabled, you might want to disable the microprofile-opentracing-smallrye subsystem.
You can use the remove operation in the management CLI to disable the MicroProfile OpenTracing feature globally for a given server.
Procedure
Remove the
microprofile-opentracing-smallryesubsystem./subsystem=microprofile-opentracing-smallrye:remove()
/subsystem=microprofile-opentracing-smallrye:remove()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server for the changes to take effect.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.3. Adding the microprofile-opentracing-smallrye subsystem Copy linkLink copied to clipboard!
You can enable the microprofile-opentracing-smallrye subsystem by adding it to the server configuration. Use the add operation in the management CLI to enable the MicroProfile OpenTracing feature globally for a given the server.
Procedure
Add the subsystem.
/subsystem=microprofile-opentracing-smallrye:add()
/subsystem=microprofile-opentracing-smallrye:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server for the changes to take effect.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.4. Installing Jaeger Copy linkLink copied to clipboard!
Install Jaeger using docker.
Prerequisites
-
dockeris installed.
Procedure
Install Jaeger using
dockerby issuing the following command in CLI:docker run -d --name jaeger -p 6831:6831/udp -p 5778:5778 -p 14268:14268 -p 16686:16686 jaegertracing/all-in-one:1.16
$ docker run -d --name jaeger -p 6831:6831/udp -p 5778:5778 -p 14268:14268 -p 16686:16686 jaegertracing/all-in-one:1.16Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. MicroProfile Config configuration Copy linkLink copied to clipboard!
3.2.1. Adding properties in a ConfigSource management resource Copy linkLink copied to clipboard!
You can store properties directly in a config-source subsystem as a management resource.
Procedure
Create a ConfigSource and add a property:
/subsystem=microprofile-config-smallrye/config-source=props:add(properties={"name" = "jim"})/subsystem=microprofile-config-smallrye/config-source=props:add(properties={"name" = "jim"})Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.2. Configuring directories as ConfigSources Copy linkLink copied to clipboard!
When a property is stored in a directory as a file, the file-name is the name of a property and the file content is the value of the property.
Procedure
Create a directory where you want to store the files:
mkdir -p ~/config/prop-files/
$ mkdir -p ~/config/prop-files/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Navigate to the directory:
cd ~/config/prop-files/
$ cd ~/config/prop-files/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a file
nameto store the value for the propertyname:touch name
$ touch nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the value of the property to the file:
echo "jim" > name
$ echo "jim" > nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a ConfigSource in which the file name is the property and the file contents the value of the property:
/subsystem=microprofile-config-smallrye/config-source=file-props:add(dir={path=~/config/prop-files})/subsystem=microprofile-config-smallrye/config-source=file-props:add(dir={path=~/config/prop-files})Copy to Clipboard Copied! Toggle word wrap Toggle overflow This results in the following XML configuration:
<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"> <config-source name="file-props"> <dir path="/etc/config/prop-files"/> </config-source> </subsystem><subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"> <config-source name="file-props"> <dir path="/etc/config/prop-files"/> </config-source> </subsystem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2.3. Obtaining ConfigSource from a ConfigSource class Copy linkLink copied to clipboard!
You can create and configure a custom org.eclipse.microprofile.config.spi.ConfigSource implementation class to provide a source for the configuration values.
Procedure
The following management CLI command creates a
ConfigSourcefor the implementation class namedorg.example.MyConfigSourcethat is provided by a JBoss module namedorg.example.If you want to use a
ConfigSourcefrom theorg.examplemodule, add the<module name="org.eclipse.microprofile.config.api"/>dependency to thepath/to/org/example/main/module.xmlfile./subsystem=microprofile-config-smallrye/config-source=my-config-source:add(class={name=org.example.MyConfigSource, module=org.example})/subsystem=microprofile-config-smallrye/config-source=my-config-source:add(class={name=org.example.MyConfigSource, module=org.example})Copy to Clipboard Copied! Toggle word wrap Toggle overflow This command results in the following XML configuration for the
microprofile-config-smallryesubsystem.<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"> <config-source name="my-config-source"> <class name="org.example.MyConfigSource" module="org.example"/> </config-source> </subsystem><subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"> <config-source name="my-config-source"> <class name="org.example.MyConfigSource" module="org.example"/> </config-source> </subsystem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Properties provided by the custom org.eclipse.microprofile.config.spi.ConfigSource implementation class are available to any JBoss EAP deployment.
3.2.4. Obtaining ConfigSource configuration from a ConfigSourceProvider class Copy linkLink copied to clipboard!
You can create and configure a custom org.eclipse.microprofile.config.spi.ConfigSourceProvider implementation class that registers implementations for multiple ConfigSource instances.
Procedure
Create a
config-source-provider:/subsystem=microprofile-config-smallrye/config-source-provider=my-config-source-provider:add(class={name=org.example.MyConfigSourceProvider, module=org.example})/subsystem=microprofile-config-smallrye/config-source-provider=my-config-source-provider:add(class={name=org.example.MyConfigSourceProvider, module=org.example})Copy to Clipboard Copied! Toggle word wrap Toggle overflow The command creates a
config-source-providerfor the implementation class namedorg.example.MyConfigSourceProviderthat is provided by a JBoss Module namedorg.example.If you want to use a
config-source-providerfrom theorg.examplemodule, add the<module name="org.eclipse.microprofile.config.api"/>dependency to thepath/to/org/example/main/module.xmlfile.This command results in the following XML configuration for the
microprofile-config-smallryesubsystem:<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"> <config-source-provider name="my-config-source-provider"> <class name="org.example.MyConfigSourceProvider" module="org.example"/> </config-source-provider> </subsystem><subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"> <config-source-provider name="my-config-source-provider"> <class name="org.example.MyConfigSourceProvider" module="org.example"/> </config-source-provider> </subsystem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Properties provided by the ConfigSourceProvider implementation are available to any JBoss EAP deployment.
Additional resources
- For information about how to add a global module to the JBoss EAP server, see Define Global Modules in the Configuration Guide for JBoss EAP.
3.3. MicroProfile Fault Tolerance configuration Copy linkLink copied to clipboard!
3.3.1. Adding the MicroProfile Fault Tolerance extension Copy linkLink copied to clipboard!
The MicroProfile Fault Tolerance extension is included in standalone-microprofile.xml and standalone-microprofile-ha.xml configurations that are provided as part of JBoss EAP XP.
The extension is not included in the standard standalone.xml configuration. To use the extension, you must manually enable it.
Prerequisites
- EAP XP pack is installed.
Procedure
Add the MicroProfile Fault Tolerance extension using the following management CLI command:
/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enable the
microprofile-fault-tolerance-smallryesubsystem using the following managenent command:/subsystem=microprofile-fault-tolerance-smallrye:add
/subsystem=microprofile-fault-tolerance-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server with the following management command:
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. MicroProfile Health configuration Copy linkLink copied to clipboard!
3.4.1. Examining health using the management CLI Copy linkLink copied to clipboard!
You can check system health using the management CLI.
Procedure
Examine health:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.2. Examining health using the management console Copy linkLink copied to clipboard!
You can check system health using the management console.
A check runtime operation shows the health checks and the global outcome as boolean value.
Procedure
- Navigate to the Runtime tab and select the server.
- In the Monitor column, click MicroProfile Health → View.
3.4.3. Examining health using the HTTP endpoint Copy linkLink copied to clipboard!
Health check is automatically deployed to the health context on JBoss EAP, so you can obtain the current health using the HTTP endpoint.
The default address for the /health endpoint, accessible from the management interface, is http://127.0.0.1:9990/health.
Procedure
To obtain the current health of the server using the HTTP endpoint, use the following URL:.
http://<host>:<port>/health
http://<host>:<port>/healthCopy to Clipboard Copied! Toggle word wrap Toggle overflow Accessing this context displays the health check in JSON format, indicating if the server is healthy.
3.4.4. Enabling authentication for MicroProfile Health Copy linkLink copied to clipboard!
You can configure the health context to require authentication for access.
Procedure
Set the
security-enabledattribute totrueon themicroprofile-health-smallryesubsystem./subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
/subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server for the changes to take effect.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Any subsequent attempt to access the /health endpoint triggers an authentication prompt.
3.4.5. Readiness probes that determine server health and readiness Copy linkLink copied to clipboard!
JBoss EAP XP 3.0.0 supports three readiness probes to determine server health and readiness.
-
server-status- returnsUPwhen the server-state isrunning. -
boot-errors- returnsUPwhen the probe detects no boot errors. -
deployment-status- returnsUPwhen the status for all deployments isOK.
These readiness probes are enabled by default. You can disable the probes using the MicroProfile Config property mp.health.disable-default-procedures.
The following example illustrates the use of the three probes with the check operation:
3.4.6. Global status when probes are not defined Copy linkLink copied to clipboard!
The :empty-readiness-checks-status and :empty-liveness-checks-status management attributes specify the global status when no readiness or liveness probes are defined.
These attributes allow applications to report ‘DOWN’ until their probes verify that the application is ready or live. By default, applications report ‘UP’.
The
:empty-readiness-checks-statusattribute specifies the global status forreadinessprobes if noreadinessprobes have been defined:/subsystem=microprofile-health-smallrye:read-attribute(name=empty-readiness-checks-status) { "outcome" => "success", "result" => expression "${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}" }/subsystem=microprofile-health-smallrye:read-attribute(name=empty-readiness-checks-status) { "outcome" => "success", "result" => expression "${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
:empty-liveness-checks-statusattribute specifies the global status forlivenessprobes if nolivenessprobes have been defined:/subsystem=microprofile-health-smallrye:read-attribute(name=empty-liveness-checks-status) { "outcome" => "success", "result" => expression "${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" }/subsystem=microprofile-health-smallrye:read-attribute(name=empty-liveness-checks-status) { "outcome" => "success", "result" => expression "${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
/healthHTTP endpoint and the:checkoperation that check bothreadinessandlivenessprobes also take into account these attributes.
You can also modify these attributes as shown in the following example:
3.5. MicroProfile JWT configuration Copy linkLink copied to clipboard!
3.5.1. Enabling microprofile-jwt-smallrye subsystem Copy linkLink copied to clipboard!
The MicroProfile JWT integration is provided by the microprofile-jwt-smallrye subsystem and is included in the default configuration. If the subsystem is not present in the default configuration, you can add it as follows.
Prerequisites
- EAP XP is installed.
Procedure
Enable the MicroProfile JWT smallrye extension in JBoss EAP:
/extension=org.wildfly.extension.microprofile.jwt-smallrye:add
/extension=org.wildfly.extension.microprofile.jwt-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enable the
microprofile-jwt-smallryesubsystem:/subsystem=microprofile-jwt-smallrye:add
/subsystem=microprofile-jwt-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server:
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The microprofile-jwt-smallrye subsystem is enabled.
3.6. MicroProfile Metrics administration Copy linkLink copied to clipboard!
3.6.1. Metrics available on the management interface Copy linkLink copied to clipboard!
The JBoss EAP subsystem metrics are exposed in Prometheus format.
Metrics are automatically available on the JBoss EAP management interface, with the following contexts:
-
/metrics/- Contains metrics specified in the MicroProfile 3.0 specification. -
/metrics/vendor- Contains vendor-specific metrics, such as memory pools. -
/metrics/application- Contains metrics from deployed applications and subsystems that use the MicroProfile Metrics API.
The metric names are based on subsystem and attribute names. For example, the subsystem undertow exposes a metric attribute request-count for every servlet in an application deployment. The name of this metric is jboss_undertow_request_count. The prefix jboss identifies JBoss EAP as the source of the metrics.
3.6.2. Examining metrics using the HTTP endpoint Copy linkLink copied to clipboard!
Examine the metrics that are available on the JBoss EAP management interface using the HTTP endpoint.
Procedure
Use the curl command:
curl -v http://localhost:9990/metrics | grep -i type
$ curl -v http://localhost:9990/metrics | grep -i typeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6.3. Enabling Authentication for the MicroProfile Metrics HTTP Endpoint Copy linkLink copied to clipboard!
Configure the metrics context to require users to be authorized to access the context. This configuration extends to all the subcontexts of the metrics context.
Procedure
Set the
security-enabledattribute totrueon themicroprofile-metrics-smallryesubsystem./subsystem=microprofile-metrics-smallrye:write-attribute(name=security-enabled,value=true)
/subsystem=microprofile-metrics-smallrye:write-attribute(name=security-enabled,value=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server for the changes to take effect.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Any subsequent attempt to access the metrics endpoint results in an authentication prompt.
3.6.4. Obtaining the request count for a web service Copy linkLink copied to clipboard!
Obtain the request count for a web service that exposes its request count metric.
The following procedure uses helloworld-rs quickstart as the web service for obtaining request count. The quickstart is available at Download the quickstart from: jboss-eap-quickstarts.
Prerequsites
- The web service exposes request count.
Procedure
Enable statistics for the
undertowsubsystem:Start the standalone server with statistics enabled:
./standalone.sh -Dwildfly.statistics-enabled=true
$ ./standalone.sh -Dwildfly.statistics-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow For an already running server, enable the statistics for the
undertowsubsystem:/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)
/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Deploy the
helloworld-rsquickstart:In the root directory of the quickstart, deploy the web application using Maven:
mvn clean install wildfly:deploy
$ mvn clean install wildfly:deployCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Query the HTTP endpoint in the CLI using the
curlcommand and filter forrequest_count:curl -v http://localhost:9990/metrics | grep request_count
$ curl -v http://localhost:9990/metrics | grep request_countCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output:
jboss_undertow_request_count_total{server="default-server",http_listener="default",} 0.0jboss_undertow_request_count_total{server="default-server",http_listener="default",} 0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow The attribute value returned is
0.0.- Access the quickstart, located at http://localhost:8080/helloworld-rs/, in a web browser and click any of the links.
Query the HTTP endpoint from the CLI again:
curl -v http://localhost:9990/metrics | grep request_count
$ curl -v http://localhost:9990/metrics | grep request_countCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output:
jboss_undertow_request_count_total{server="default-server",http_listener="default",} 1.0jboss_undertow_request_count_total{server="default-server",http_listener="default",} 1.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow The value is updated to
1.0.Repeat the last two steps to verify that the request count is updated.
3.7. MicroProfile OpenAPI administration Copy linkLink copied to clipboard!
3.7.1. Enabling MicroProfile OpenAPI Copy linkLink copied to clipboard!
The microprofile-openapi-smallrye subsystem is provided in the standalone-microprofile.xml configuration. However, JBoss EAP XP uses the standalone.xml by default. You must include the subsystem in standalone.xml to use it.
Alternatively, you can follow the procedure Updating standalone configurations with MicroProfile subsystems and extensions to update the standalone.xml configuration file.
Procedure
Enable the MicroProfile OpenAPI smallrye extension in JBoss EAP:
/extension=org.wildfly.extension.microprofile.openapi-smallrye:add()
/extension=org.wildfly.extension.microprofile.openapi-smallrye:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable the
microprofile-openapi-smallryesubsystem using the following management command:/subsystem=microprofile-openapi-smallrye:add()
/subsystem=microprofile-openapi-smallrye:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The microprofile-openapi-smallrye subsystem is enabled.
3.7.2. Requesting an MicroProfile OpenAPI document using Accept HTTP header Copy linkLink copied to clipboard!
Request an MicroProfile OpenAPI document, in the JSON format, from a deployment using an Accept HTTP header.
By default, the OpenAPI endpoint returns a YAML document.
Prerequisites
- The deployment being queried is configured to return an MicroProfile OpenAPI document.
Procedure
Issue the following
curlcommand to query the/openapiendpoint of the deployment:curl -v -H'Accept: application/json' http://localhost:8080/openapi
$ curl -v -H'Accept: application/json' http://localhost:8080/openapi < HTTP/1.1 200 OK ... {"openapi": "3.0.1" ... }Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace http://localhost:8080 with the URL and port of the deployment.
The Accept header indicates that the JSON document is to be returned using the
application/jsonstring.
3.7.3. Requesting an MicroProfile OpenAPI document using an HTTP parameter Copy linkLink copied to clipboard!
Request an MicroProfile OpenAPI document, in the JSON format, from a deployment using a query parameter in an HTTP request.
By default, the OpenAPI endpoint returns a YAML document.
Prerequisites
- The deployment being queried is configured to return an MicroProfile OpenAPI document.
Procedure
Issue the following
curlcommand to query the/openapiendpoint of the deployment:curl -v http://localhost:8080/openapi?format=JSON
$ curl -v http://localhost:8080/openapi?format=JSON < HTTP/1.1 200 OK ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace http://localhost:8080 with the URL and port of the deployment.
The HTTP parameter
format=JSONindicates that JSON document is to be returned.
3.7.4. Configuring JBoss EAP to serve a static OpenAPI document Copy linkLink copied to clipboard!
Configure JBoss EAP to serve a static OpenAPI document that describes the REST services for the host.
When JBoss EAP is configured to serve a static OpenAPI document, the static OpenAPI document is processed before any Jakarta RESTful Web Services and MicroProfile OpenAPI annotations.
In a production environment, disable annotation processing when serving a static document. Disabling annotation processing ensures that an immutable and versioned API contract is available for clients.
Procedure
Create a directory in the application source tree:
mkdir APPLICATION_ROOT/src/main/webapp/META-INF
$ mkdir APPLICATION_ROOT/src/main/webapp/META-INFCopy to Clipboard Copied! Toggle word wrap Toggle overflow APPLICATION_ROOT is the directory containing the
pom.xmlconfiguration file for the application.Query the OpenAPI endpoint, redirecting the output to a file:
curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.json
$ curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow By default, the endpoint serves a YAML document,
format=JSONspecifies that a JSON document is returned.Configure the application to skip annotation scanning when processing the OpenAPI document model:
echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.properties
$ echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Rebuild the application:
mvn clean install
$ mvn clean installCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the application again using the following management CLI commands:
Undeploy the application:
undeploy microprofile-openapi.war
undeploy microprofile-openapi.warCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the application:
deploy APPLICATION_ROOT/target/microprofile-openapi.war
deploy APPLICATION_ROOT/target/microprofile-openapi.warCopy to Clipboard Copied! Toggle word wrap Toggle overflow
JBoss EAP now serves a static OpenAPI document at the OpenAPI endpoint.
3.7.5. Disabling microprofile-openapi-smallrye Copy linkLink copied to clipboard!
You can disable the microprofile-openapi-smallrye subsystem in JBoss EAP XP using the management CLI.
Procedure
Disable the
microprofile-openapi-smallryesubsystem:/subsystem=microprofile-openapi-smallrye:remove()
/subsystem=microprofile-openapi-smallrye:remove()Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8. Standalone server configuration Copy linkLink copied to clipboard!
3.8.1. Standalone server configuration files Copy linkLink copied to clipboard!
The JBoss EAP XP includes additional standalone server configuration files, standalone-microprofile.xml and standalone-microprofile-ha.xml.
Standard configuration files that are included with JBoss EAP remain unchanged. Note that JBoss EAP XP 3.0.0 does not support the use of domain.xml files or domain mode.
| Configuration File | Purpose | Included capabilities | Excluded capabilities |
|---|---|---|---|
|
| This is the default configuration that is used when you start your standalone server. | Includes information about the server, including subsystems, networking, deployments, socket bindings, and other configurable details. | Excludes subsystems necessary for messaging or high availability. |
|
| This configuration file supports applications that use MicroProfile. | Includes information about the server, including subsystems, networking, deployments, socket bindings, and other configurable details. | Excludes the following capabilities:
|
|
|
Includes default subsystems and adds the | Excludes subsystems necessary for messaging. | |
|
| This standalone file supports applications that use MicroProfile. |
Includes the | Excludes subsystems necessary for messaging. |
|
|
Includes the | ||
|
| Support for every possible subsystem. | Includes subsystems for messaging and high availability in addition to default subsystems. | |
|
| Support for the minimum subsystems necessary to use the built-in mod_cluster front-end load balancer to load balance other JBoss EAP instances. |
By default, starting JBoss EAP as a standalone server uses the standalone.xml file. To start JBoss EAP with a standalone MicroProfile configuration, use the -c argument. For example,
EAP_HOME/bin/standalone.sh -c=standalone-microprofile.xml
$ EAP_HOME/bin/standalone.sh -c=standalone-microprofile.xml
Additional Resources
3.8.2. Updating standalone configurations with MicroProfile subsystems and extensions Copy linkLink copied to clipboard!
You can update standard standalone server configuration files with MicroProfile subsystems and extensions using the docs/examples/enable-microprofile.cli script. The enable-microprofile.cli script is intended as an example script for updating standard standalone server configuration files, not custom configurations.
The enable-microprofile.cli script modifies the existing standalone server configuration and adds the following MicroProfile subsystems and extensions if they do not exist in the standalone configuration file:
-
microprofile-openapi-smallrye -
microprofile-jwt-smallrye -
microprofile-fault-tolerance-smallrye
The enable-microprofile.cli script outputs a high-level description of the modifications. The configuration is secured using the elytron subsystem. The security subsystem, if present, is removed from the configuration.
Prerequisites
- JBoss EAP XP is installed.
Procedure
Run the following CLI script to update the default
standalone.xmlserver configuration file:EAP_HOME/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli
$ EAP_HOME/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cliCopy to Clipboard Copied! Toggle word wrap Toggle overflow Select a standalone server configuration other than the default
standalone.xmlserver configuration file using the following command:EAP_HOME/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli -Dconfig=<standalone-full.xml|standalone-ha.xml|standalone-full-ha.xml>
$ EAP_HOME/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli -Dconfig=<standalone-full.xml|standalone-ha.xml|standalone-full-ha.xml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - The specified configuration file now includes MicroProfile subsystems and extensions.
Chapter 4. Develop MicroProfile Applications for JBoss EAP Copy linkLink copied to clipboard!
4.1. Maven and the JBoss EAP MicroProfile Maven repository Copy linkLink copied to clipboard!
4.1.1. Downloading the JBoss EAP MicroProfile Maven repository patch as an archive file Copy linkLink copied to clipboard!
Whenever an MicroProfile Expansion Pack is released for JBoss EAP, a corresponding patch is provided for the JBoss EAP MicroProfile Maven repository. This patch is provided as an incremental archive file that is extracted into the existing Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository. The incremental archive file does not overwrite or remove any existing files, so there is no rollback requirement.
Prerequisites
- You have set up an account on the Red Hat Customer Portal.
Procedure
- Open a browser and log in to the Red Hat Customer Portal.
- Select Downloads from the menu at the top of the page.
- Find the Red Hat JBoss Enterprise Application Platform entry in the list and select it.
- From the Product drop-down list, select JBoss EAP XP.
- From the Version drop-down list, select 2.0.0.
- Click the Releases tab.
- Find JBoss EAP XP 3.0.0 Incremental Maven Repository in the list, and then click Download.
- Save the archive file to your local directory.
Additional Resources
- To learn more about the JBoss EAP Maven repository, see About the Maven Repository in the JBoss EAP Development Guide.
4.1.2. Applying the JBoss EAP MicroProfile Maven repository patch on your local system Copy linkLink copied to clipboard!
You can install the JBoss EAP MicroProfile Maven repository patch on your local file system.
When you apply a patch in the form of an incremental archive file to the repository, new files are added to this repository. The incremental archive file does not overwrite or remove any existing files on the repository, so there is no rollback requirement.
Prerequisites
You have downloaded and installed the Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository on your local system.
- Check that you have this minor version of the Red Hat JBoss Enterprise Application Platform 7.4 Maven repository installed on your local system.
- You have downloaded the JBoss EAP XP 2.0.0 Incremental Maven repository on your local system.
Procedure
-
Locate the path to your Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository. For example,
/path/to/repo/jboss-eap-7.3.0.GA-maven-repository/maven-repository/. Extract the downloaded JBoss EAP XP 2.0.0 Incremental Maven repository directly into the directory of the Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository. For example, open a terminal and issue the following command, replacing the value for your Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository path:
unzip -o jboss-eap-xp-3.0.0-incremental-maven-repository.zip -d EAP_MAVEN_REPOSITORY_PATH
$ unzip -o jboss-eap-xp-3.0.0-incremental-maven-repository.zip -d EAP_MAVEN_REPOSITORY_PATHCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The EAP_MAVEN_REPOSITORY_PATH points to the jboss-eap-7.3.0.GA-maven-repository. For example, this procedure demonstrated the use of the path /path/to/repo/jboss-eap-7.3.0.GA-maven-repository/.
After you extract the JBoss EAP XP Incremental Maven repository into the Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository, the repository name becomes JBoss EAP MicroProfile Maven repository.
Additional Resources
- To determine the URL of the JBoss EAP Maven repository, see Determining the URL for the JBoss EAP Maven repository in the JBoss EAP Development Guide.
4.1.3. Supported JBoss EAP MicroProfile BOM Copy linkLink copied to clipboard!
JBoss EAP XP 3.0.0 includes the JBoss EAP MicroProfile BOM. This BOM is named jboss-eap-xp-microprofile, and its use case supports JBoss EAP MicroProfile APIs.
| BOM Artifact ID | Use Case |
|---|---|
| jboss-eap-xp-microprofile |
This BOM, whose |
4.1.4. Using the JBoss EAP MicroProfile Maven repository Copy linkLink copied to clipboard!
You can access the jboss-eap-xp-microprofile BOM after you install the Red Hat JBoss Enterprise Application Platform 7.4.0.GA Maven repository and apply the JBoss EAP XP Incremental Maven repository to it. The repository name then becomes JBoss EAP MicroProfile Maven repository. The BOM is shipped inside the JBoss EAP XP Incremental Maven repository.
You must configure one of the following to use the JBoss EAP MicroProfile Maven repository:
- The Maven global or user settings
- The project’s POM files
Maven settings used with a repository manager or repository on a shared server provide better control and manageability of projects.
You can use an alternative mirror to redirect all lookup requests for a specific repository to your repository manager without changing the project files.
Configuring the JBoss EAP MicroProfile Maven repository by modifying the POM file overrides the global and user Maven settings for the configured project.
Prerequisites
- You have installed the Red Hat JBoss Enterprise Application Platform 7.4 Maven repository on your local system, and you have applied the JBoss EAP XP Incremental Maven repository to it.
Procedure
- Choose a configuration method and configure the JBoss EAP MicroProfile Maven repository.
After you have configured the JBoss EAP MicroProfile Maven repository, add the
jboss-eap-xp-microprofileBOM to the project POM file. The following example shows how to configure the BOM in the<dependencyManagement>section of thepom.xmlfile:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf you do not specify a value for the
typeelement in thepom.xmlfile, Maven specifies ajarvalue for the element.
Additional Resources
- For more information about selecting methods to configure the JBoss EAP Maven repository, see Use the Maven Repository in the JBoss EAP Development Guide.
- For more information about managing dependencies, see Dependency Management.
4.2. MicroProfile Config development Copy linkLink copied to clipboard!
4.2.1. Creating a Maven project for MicroProfile Config Copy linkLink copied to clipboard!
Create a Maven project with the required dependencies and the directory structure for creating an MicroProfile Config application.
Prerequisites
- Maven is installed.
Procedure
Set up the Maven project.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This creates the directory structure for the project and
pom.xmlconfiguration file.To let the POM file automatically manage the versions for the MicroProfile Config artifact and the MicroProfile REST Client artifact in the
jboss-eap-xp-microprofileBOM, import the BOM to the<dependencyManagement>section of the project POM file.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the MicroProfile Config artifact and the MicroProfile REST Client artifact and other dependencies, managed by the BOM, to the
<dependency>section of the project POM file. The following example demonstrates adding the MicroProfile Config and the MicroProfile REST Client dependencies to the file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.2. Using MicroProfile Config property in an application Copy linkLink copied to clipboard!
Create an application that uses a configured ConfigSource.
Prerequisites
- MicroProfile Config is enabled in JBoss EAP.
- The latest POM is installed.
- The Maven project is configured for creating an MicroProfile Config application.
Procedure
Create the directory to store class files:
mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/config/
$ mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/config/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the directory containing thepom.xmlconfiguration file for the application.Navigate to the new directory:
cd APPLICATION_ROOT/src/main/java/com/example/microprofile/config/
$ cd APPLICATION_ROOT/src/main/java/com/example/microprofile/config/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create all class files described in this procedure in this directory.
Create a class file named
HelloApplication.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This class defines the application as a Jakarta RESTful Web Services application.
Create a class file named
HelloService.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file named
HelloWorld.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- A MicroProfile Config property is injected into the class with the annotation
@ConfigProperty(name="name", defaultValue="jim"). If noConfigSourceis configured, the valuejimis returned.
Create an empty file named
beans.xmlin thesrc/main/webapp/WEB-INF/directory:touch APPLICATION_ROOT/src/main/webapp/WEB-INF/beans.xml
$ touch APPLICATION_ROOT/src/main/webapp/WEB-INF/beans.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the directory containing thepom.xmlconfiguration file for the application.Navigate to the root directory of the application:
cd APPLICATION_ROOT
$ cd APPLICATION_ROOTCopy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the directory containing thepom.xmlconfiguration file for the application.Build the project:
mvn clean install wildfly:deploy
$ mvn clean install wildfly:deployCopy to Clipboard Copied! Toggle word wrap Toggle overflow Test the output:
curl http://localhost:8080/microprofile-config/config/json
$ curl http://localhost:8080/microprofile-config/config/jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is the expected output:
{"result":"Hello jim"}{"result":"Hello jim"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. MicroProfile Fault Tolerance application development Copy linkLink copied to clipboard!
4.3.1. Adding the MicroProfile Fault Tolerance extension Copy linkLink copied to clipboard!
The MicroProfile Fault Tolerance extension is included in standalone-microprofile.xml and standalone-microprofile-ha.xml configurations that are provided as part of JBoss EAP XP.
The extension is not included in the standard standalone.xml configuration. To use the extension, you must manually enable it.
Prerequisites
- EAP XP pack is installed.
Procedure
Add the MicroProfile Fault Tolerance extension using the following management CLI command:
/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add
/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enable the
microprofile-fault-tolerance-smallryesubsystem using the following managenent command:/subsystem=microprofile-fault-tolerance-smallrye:add
/subsystem=microprofile-fault-tolerance-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server with the following management command:
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.2. Configuring Maven project for MicroProfile Fault Tolerance Copy linkLink copied to clipboard!
Create a Maven project with the required dependencies and the directory structure for creating an MicroProfile Fault Tolerance application.
Prerequisites
- Maven is installed.
Procedure
Set up the Maven project:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The command creates the directory structure for the project and the
pom.xmlconfiguration file.To let the POM file automatically manage the versions for the MicroProfile Fault Tolerance artifact in the
jboss-eap-xp-microprofileBOM, import the BOM to the<dependencyManagement>section of the project POM file.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace ${version.microprofile.bom} with the installed version of BOM.
Add the MicroProfile Fault Tolerance artifact, managed by the BOM, to the
<dependency>section of the project POM file. The following example demonstrates adding the MicroProfile Fault Tolerance dependency to the file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.3. Creating a fault tolerant application Copy linkLink copied to clipboard!
Create a fault-tolerant application that implements retry, timeout, and fallback patterns for fault tolerance.
Prerequisites
- Maven dependencies have been configured.
Procedure
Create the directory to store class files:
mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/faulttolerance
$ mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/faulttoleranceCopy to Clipboard Copied! Toggle word wrap Toggle overflow APPLICATION_ROOT is the directory containing the
pom.xmlconfiguration file for the application.Navigate to the new directory:
cd APPLICATION_ROOT/src/main/java/com/example/microprofile/faulttolerance
$ cd APPLICATION_ROOT/src/main/java/com/example/microprofile/faulttoleranceCopy to Clipboard Copied! Toggle word wrap Toggle overflow For the following steps, create all class files in the new directory.
Create a simple entity representing a coffee sample as
Coffee.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file
CoffeeApplication.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Jakarta Contexts and Dependency Injection Bean as
CoffeeRepositoryService.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file
CoffeeResource.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Navigate to the root directory of the application:
cd APPLICATION_ROOT
$ cd APPLICATION_ROOTCopy to Clipboard Copied! Toggle word wrap Toggle overflow Build the application using the following Maven command:
mvn clean install wildfly:deploy
$ mvn clean install wildfly:deployCopy to Clipboard Copied! Toggle word wrap Toggle overflow Access the application at
http://localhost:8080/microprofile-fault-tolerance/coffee.
Additional Resources
-
For a detailed example of fault tolerant application, which includes artificial failures to test the fault tolerance of the application, see the
microprofile-fault-tolerancequickstart.
4.4. MicroProfile Health development Copy linkLink copied to clipboard!
4.4.1. Custom health check example Copy linkLink copied to clipboard!
The default implementation provided by the microprofile-health-smallrye subsystem performs a basic health check. For more detailed information, on either the server or application status, custom health checks may be included. Any Jakarta Contexts and Dependency Injection beans that include the org.eclipse.microprofile.health.Liveness annotation or the org.eclipse.microprofile.health.Readiness annotation at the class level are automatically discovered and invoked at runtime.
The following example demonstrates how to create a new implementation of a health check that returns an UP state.
Once deployed, any subsequent health check queries include the custom checks, as demostrated in the following example.
You can use the following for liveness and readiness checks:
-
/subsystem=microprofile-health-smallrye:check-live -
/subsystem=microprofile-health-smallrye:check-ready
4.4.2. The @Liveness annotation example Copy linkLink copied to clipboard!
The following is an example of using the @Liveness annotation in an application.
4.4.3. The @Readiness annotation example Copy linkLink copied to clipboard!
The following example demonstrates checking connection to a database. If the database is down, the readiness check reports error.
4.5. MicroProfile JWT application development Copy linkLink copied to clipboard!
4.5.1. Enabling microprofile-jwt-smallrye subsystem Copy linkLink copied to clipboard!
The MicroProfile JWT integration is provided by the microprofile-jwt-smallrye subsystem and is included in the default configuration. If the subsystem is not present in the default configuration, you can add it as follows.
Prerequisites
- EAP XP is installed.
Procedure
Enable the MicroProfile JWT smallrye extension in JBoss EAP:
/extension=org.wildfly.extension.microprofile.jwt-smallrye:add
/extension=org.wildfly.extension.microprofile.jwt-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enable the
microprofile-jwt-smallryesubsystem:/subsystem=microprofile-jwt-smallrye:add
/subsystem=microprofile-jwt-smallrye:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server:
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The microprofile-jwt-smallrye subsystem is enabled.
4.5.2. Configuring Maven project for developing JWT applications Copy linkLink copied to clipboard!
Create a Maven project with the required dependencies and the directory structure for developing a JWT application.
Prerequisites
- Maven is installed.
-
microprofile-jwt-smallryesubsystem is enabled.
Procedure
Set up the maven project:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The command creates the directory structure for the project and the
pom.xmlconfiguration file.To let the POM file automatically manage the versions for the MicroProfile JWT artifact in the
jboss-eap-xp-microprofileBOM, import the BOM to the<dependencyManagement>section of the project POM file.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace ${version.microprofile.bom} with the installed version of BOM.
Add the MicroProfile JWT artifact, managed by the BOM, to the
<dependency>section of the project POM file. The following example demonstrates adding the MicroProfile JWT dependency to the file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.3. Creating an application with MicroProfile JWT Copy linkLink copied to clipboard!
Create an application that authenticates requests based on JWT tokens and implements authorization based on the identity of the token bearer.
The following procedure provides example code for generating tokens. For a production environment, use an identity provider such as Red Hat single sign-on (SSO).
Prerequisites
- Maven project is configured with the correct dependencies.
Procedure
Create a token generator.
This step serves as a reference. For a production environment, use an identity provider such as Red Hat SSO.
Create a directory
src/test/javafor token the generator utility and navigate to it:mkdir -p src/test/java cd src/test/java
$ mkdir -p src/test/java $ cd src/test/javaCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file
TokenUtil.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Create the
web.xmlfile in thesrc/main/webapp/WEB-INFdirectory with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file
SampleEndPoint.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The methods annotated with
@Pathare the Jakarta RESTful Web Services endpoints.The annotation
@Claimdefines a JWT claim.Create a class file
App.javato enable Jakarta RESTful Web Services:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The annotation
@LoginConfig(authMethod="MP-JWT", realmName="MP JWT Realm")enables JWT RBAC during deployment.Compile the application with the following Maven command:
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate JWT token using the token generator utility:
mvn exec:java -Dexec.mainClass=org.wildfly.quickstarts.mpjwt.TokenUtil -Dexec.classpathScope=test -Dexec.args="testUser 2017-09-15 Echoer Subscriber"
$ mvn exec:java -Dexec.mainClass=org.wildfly.quickstarts.mpjwt.TokenUtil -Dexec.classpathScope=test -Dexec.args="testUser 2017-09-15 Echoer Subscriber"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Build and deploy the application using the following Maven command:
mvn package wildfly:deploy
$ mvn package wildfly:deployCopy to Clipboard Copied! Toggle word wrap Toggle overflow Test the application.
Call the
Sample/subscriptionendpoint using the bearer token:curl -H "Authorization: Bearer ey..rg" http://localhost:8080/microprofile-jwt/rest/Sample/subscription
$ curl -H "Authorization: Bearer ey..rg" http://localhost:8080/microprofile-jwt/rest/Sample/subscriptionCopy to Clipboard Copied! Toggle word wrap Toggle overflow Call the
Sample/birthdayendpoint:curl -H "Authorization: Bearer ey..rg" http://localhost:8080/microprofile-jwt/rest/Sample/birthday
$ curl -H "Authorization: Bearer ey..rg" http://localhost:8080/microprofile-jwt/rest/Sample/birthdayCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6. MicroProfile Metrics development Copy linkLink copied to clipboard!
4.6.1. Creating an MicroProfile Metrics application Copy linkLink copied to clipboard!
Create an application that returns the number of requests made to the application.
Procedure
Create a class file
HelloService.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file
HelloWorld.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update the
pom.xmlfile to include the following dependency:<dependency> <groupId>org.eclipse.microprofile.metrics</groupId> <artifactId>microprofile-metrics-api</artifactId> <scope>provided</scope> </dependency><dependency> <groupId>org.eclipse.microprofile.metrics</groupId> <artifactId>microprofile-metrics-api</artifactId> <scope>provided</scope> </dependency>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Build the application using the following Maven command:
mvn clean install wildfly:deploy
$ mvn clean install wildfly:deployCopy to Clipboard Copied! Toggle word wrap Toggle overflow Test the metrics:
Issue the following command in the CLI:
curl -v http://localhost:9990/metrics | grep request_count | grep helloworld-rs-metrics
$ curl -v http://localhost:9990/metrics | grep request_count | grep helloworld-rs-metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output:
jboss_undertow_request_count_total{deployment="helloworld-rs-metrics.war",servlet="org.jboss.as.quickstarts.rshelloworld.JAXActivator",subdeployment="helloworld-rs-metrics.war",microprofile_scope="vendor"} 0.0jboss_undertow_request_count_total{deployment="helloworld-rs-metrics.war",servlet="org.jboss.as.quickstarts.rshelloworld.JAXActivator",subdeployment="helloworld-rs-metrics.war",microprofile_scope="vendor"} 0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow - In a browser, navigate to the URL http://localhost:8080/helloworld-rs/rest/json.
Re-Issue the following command in the CLI:
curl -v http://localhost:9990/metrics | grep request_count | grep helloworld-rs-metrics
$ curl -v http://localhost:9990/metrics | grep request_count | grep helloworld-rs-metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output:
jboss_undertow_request_count_total{deployment="helloworld-rs-metrics.war",servlet="org.jboss.as.quickstarts.rshelloworld.JAXActivator",subdeployment="helloworld-rs-metrics.war",microprofile_scope="vendor"} 1.0jboss_undertow_request_count_total{deployment="helloworld-rs-metrics.war",servlet="org.jboss.as.quickstarts.rshelloworld.JAXActivator",subdeployment="helloworld-rs-metrics.war",microprofile_scope="vendor"} 1.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7. Developing an MicroProfile OpenAPI application Copy linkLink copied to clipboard!
4.7.1. Enabling MicroProfile OpenAPI Copy linkLink copied to clipboard!
The microprofile-openapi-smallrye subsystem is provided in the standalone-microprofile.xml configuration. However, JBoss EAP XP uses the standalone.xml by default. You must include the subsystem in standalone.xml to use it.
Alternatively, you can follow the procedure Updating standalone configurations with MicroProfile subsystems and extensions to update the standalone.xml configuration file.
Procedure
Enable the MicroProfile OpenAPI smallrye extension in JBoss EAP:
/extension=org.wildfly.extension.microprofile.openapi-smallrye:add()
/extension=org.wildfly.extension.microprofile.openapi-smallrye:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable the
microprofile-openapi-smallryesubsystem using the following management command:/subsystem=microprofile-openapi-smallrye:add()
/subsystem=microprofile-openapi-smallrye:add()Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reload the server.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The microprofile-openapi-smallrye subsystem is enabled.
4.7.2. Configuring Maven project for MicroProfile OpenAPI Copy linkLink copied to clipboard!
Create a Maven project to set up the dependencies for creating an MicroProfile OpenAPI application.
Prerequisites
- Maven is installed.
- JBoss EAP Maven repository is configured.
Procedure
Initialize the project:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The command creates the directory structure for the project and the
pom.xmlconfiguration file.Edit the
pom.xmlconfiguration file to contain:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use the
pom.xmlconfiguration file and directory structure to create an application.
4.7.3. Creating an MicroProfile OpenAPI application Copy linkLink copied to clipboard!
Create an application that returns an OpenAPI v3 document.
Prerequisites
- Maven project is configured for creating an MicroProfile OpenAPI application.
Procedure
Create the directory to store class files:
mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/openapi/
$ mkdir -p APPLICATION_ROOT/src/main/java/com/example/microprofile/openapi/Copy to Clipboard Copied! Toggle word wrap Toggle overflow APPLICATION_ROOT is the directory containing the
pom.xmlconfiguration file for the application.Navigate to the new directory:
cd APPLICATION_ROOT/src/main/java/com/example/microprofile/openapi/
$ cd APPLICATION_ROOT/src/main/java/com/example/microprofile/openapi/Copy to Clipboard Copied! Toggle word wrap Toggle overflow All the class files in the following steps must be created in this directory.
Create the class file
InventoryApplication.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This class serves as the REST endpoint for the application.
Create a class file
Fruit.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a class file
FruitResource.javawith the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Navigate to the root directory of the application:
cd APPLICATION_ROOT
$ cd APPLICATION_ROOTCopy to Clipboard Copied! Toggle word wrap Toggle overflow Build and deploy the application using the following Maven command:
mvn wildfly:deploy
$ mvn wildfly:deployCopy to Clipboard Copied! Toggle word wrap Toggle overflow Test the application.
Access the OpenAPI documentation of the sample application using
curl:curl http://localhost:8080/openapi
$ curl http://localhost:8080/openapiCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following output is returned:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional Resources
- For a list of annotations defined in MicroProfile SmallRye OpenAPI, see MicroProfile OpenAPI annotations.
4.7.4. Configuring JBoss EAP to serve a static OpenAPI document Copy linkLink copied to clipboard!
Configure JBoss EAP to serve a static OpenAPI document that describes the REST services for the host.
When JBoss EAP is configured to serve a static OpenAPI document, the static OpenAPI document is processed before any Jakarta RESTful Web Services and MicroProfile OpenAPI annotations.
In a production environment, disable annotation processing when serving a static document. Disabling annotation processing ensures that an immutable and versioned API contract is available for clients.
Procedure
Create a directory in the application source tree:
mkdir APPLICATION_ROOT/src/main/webapp/META-INF
$ mkdir APPLICATION_ROOT/src/main/webapp/META-INFCopy to Clipboard Copied! Toggle word wrap Toggle overflow APPLICATION_ROOT is the directory containing the
pom.xmlconfiguration file for the application.Query the OpenAPI endpoint, redirecting the output to a file:
curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.json
$ curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow By default, the endpoint serves a YAML document,
format=JSONspecifies that a JSON document is returned.Configure the application to skip annotation scanning when processing the OpenAPI document model:
echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.properties
$ echo "mp.openapi.scan.disable=true" > APPLICATION_ROOT/src/main/webapp/META-INF/microprofile-config.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Rebuild the application:
mvn clean install
$ mvn clean installCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the application again using the following management CLI commands:
Undeploy the application:
undeploy microprofile-openapi.war
undeploy microprofile-openapi.warCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the application:
deploy APPLICATION_ROOT/target/microprofile-openapi.war
deploy APPLICATION_ROOT/target/microprofile-openapi.warCopy to Clipboard Copied! Toggle word wrap Toggle overflow
JBoss EAP now serves a static OpenAPI document at the OpenAPI endpoint.
4.8. MicroProfile REST Client development Copy linkLink copied to clipboard!
4.8.1. A comparison of MicroProfile REST client and Jakarta RESTful Web Services syntaxes Copy linkLink copied to clipboard!
The MicroProfile REST client enables a version of distributed object communication, which is also implemented in CORBA, Java Remote Method Invocation (RMI), the JBoss Remoting Project, and RESTEasy. For example, consider the resource:
The following example demonstrates the use of the Jakarta RESTful Web Services-native way to access the TestResource class:
Client client = ClientBuilder.newClient();
String response = client.target("http://localhost:8081/test").request().get(String.class);
Client client = ClientBuilder.newClient();
String response = client.target("http://localhost:8081/test").request().get(String.class);
However, Microprofile REST client supports a more intuitive syntax by directly calling the test() method, as the following example demonstrates:
In the preceding example, making calls on the TestResource class becomes much easier with the TestResourceIntf class, as illustrated by the call service.test().
The following example is a more elaborate version of the TestResourceIntf class:
Calling the service.test("p", "q", "e") method results in an HTTP message as shown in the following example:
4.8.2. Programmatic registration of providers in MicroProfile REST client Copy linkLink copied to clipboard!
With the MicroProfile REST client, you can configure the client environment by registering providers. For example:
TestResourceIntf service = RestClientBuilder.newBuilder()
.baseUrl(http://localhost:8081/))
.register(MyClientResponseFilter.class)
.register(MyMessageBodyReader.class)
.build(TestResourceIntf.class);
TestResourceIntf service = RestClientBuilder.newBuilder()
.baseUrl(http://localhost:8081/))
.register(MyClientResponseFilter.class)
.register(MyMessageBodyReader.class)
.build(TestResourceIntf.class);
4.8.3. Declarative registration of providers in MicroProfile REST client Copy linkLink copied to clipboard!
Use the MicroProfile REST client to register providers declaratively by adding the org.eclipse.microprofile.rest.client.annotation.RegisterProvider annotation to the target interface, as shown in the following example:
Declaring the MyClientResponseFilter class and the MyMessageBodyReader class with annotations eliminates the need to call the RestClientBuilder.register() method.
4.8.4. Declarative specification of headers in MicroProfile REST client Copy linkLink copied to clipboard!
You can specify a header for an HTTP request in the following ways:
- By annotating one of the resource method parameters.
-
By declaratively using the
org.eclipse.microprofile.rest.client.annotation.ClientHeaderParamannotation.
The following example illustrates setting a header by annotating one of the resource method parameters with the annotation @HeaderParam:
@POST @Produces(MediaType.TEXT_PLAIN) @Consumes(MediaType.TEXT_PLAIN) String contentLang(@HeaderParam(HttpHeaders.CONTENT_LANGUAGE) String contentLanguage, String subject);
@POST
@Produces(MediaType.TEXT_PLAIN)
@Consumes(MediaType.TEXT_PLAIN)
String contentLang(@HeaderParam(HttpHeaders.CONTENT_LANGUAGE) String contentLanguage, String subject);
The following example illustrates setting a header using the org.eclipse.microprofile.rest.client.annotation.ClientHeaderParam annotation:
4.8.5. ResponseExceptionMapper in MicroProfile REST client Copy linkLink copied to clipboard!
The org.eclipse.microprofile.rest.client.ext.ResponseExceptionMapper class is the client-side inverse of the javax.ws.rs.ext.ExceptionMapper class, which is defined in Jakarta RESTful Web Services. The ExceptionMapper.toResponse() method turns an Exception class thrown during the server-side processing into a Response class. The ResponseExceptionMapper.toThrowable() method turns a Response class received on the client-side with an HTTP error status into an Exception class.
You can register the ResponseExceptionMapper class either programmatically or declaratively. In the absence of a registered ResponseExceptionMapper class, a default ResponseExceptionMapper class maps any response with status >= 400 to a WebApplicationException class.
4.8.6. Context dependency injection with MicroProfile REST client Copy linkLink copied to clipboard!
With the MicroProfile REST client, you must annotate any interface that is managed as a Jakarta contexts and dependency injection (Jakarta Contexts and Dependency Injection) bean with the @RegisterRestClient class. For example:
Here, the MicroProfile REST client implementation creates a client for a TestDataBase class service, allowing easy access by the TestResourceImpl class. However, it does not include the information about the path to the TestDataBase class implementation. This information can be supplied by the optional @RegisterProvider parameter baseUri:
This indicates that you can access the implementation of TestDataBase at https://localhost:8080/webapp. You can also use MicroProfile configuration to supply the information externally:
<fully qualified name of TestDataBase>/mp-rest/url=<URL>
<fully qualified name of TestDataBase>/mp-rest/url=<URL>
For example, the following property indicates that you can access an implementation of the com.bluemonkeydiamond.TestDatabase class at https://localhost:8080/webapp:
com.bluemonkeydiamond.TestDatabase/mp-rest/url=https://localhost:8080/webapp
com.bluemonkeydiamond.TestDatabase/mp-rest/url=https://localhost:8080/webapp
You can supply a number of other properties to Jakarta Contexts and Dependency Injection clients. For example, com.mycompany.remoteServices.MyServiceClient/mp-rest/providers, comma-separated list of fully-qualified provider class names to include in the client.
Chapter 5. Build and run microservices applications on the OpenShift image for JBoss EAP XP Copy linkLink copied to clipboard!
You can build and run your microservices applications on the OpenShift image for JBoss EAP XP.
JBoss EAP XP is supported only on OpenShift 4 and later versions.
Use the following workflow to build and run a microservices application on the OpenShift image for JBoss EAP XP by using the source-to-image (S2I) process.
The OpenShift images for JBoss EAP XP 3.0.0 provide a default standalone configuration file, which is based on the standalone-microprofile-ha.xml file. For more information about the server configuration files included in JBoss EAP XP, see the Standalone server configuration files section.
This workflow uses the microprofile-config quickstart as an example. The quickstart provides a small, specific working example that can be used as a reference for your own project. See the microprofile-config quickstart that ships with JBoss EAP XP 3.0.0 for more information.
Additional resources
- For more information about the server configuration files included in JBoss EAP XP, see Standalone server configuration files.
5.1. Preparing OpenShift for application deployment Copy linkLink copied to clipboard!
Prepare OpenShift for application deployment.
Prerequisites
You have installed an operational OpenShift instance. For more information, see the Installing and Configuring OpenShift Container Platform Clusters book on Red Hat Customer Portal.
Procedure
-
Log in to your OpenShift instance using the
oc logincommand. Create a new project in OpenShift.
A project allows a group of users to organize and manage content separately from other groups. You can create a project in OpenShift using the following command.
oc new-project PROJECT_NAME
$ oc new-project PROJECT_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow For example, for the
microprofile-configquickstart, create a new project namedeap-demousing the following command.oc new-project eap-demo
$ oc new-project eap-demoCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. Configuring authentication to the Red Hat Container Registry Copy linkLink copied to clipboard!
Before you can import and use the OpenShift image for JBoss EAP XP, you must configure authentication to the Red Hat Container Registry.
Create an authentication token using a registry service account to configure access to the Red Hat Container Registry. You need not use or store your Red Hat account’s username and password in your OpenShift configuration when you use an authentication token.
Procedure
- Follow the instructions on Red Hat Customer Portal to create an authentication token using a Registry Service Account management application.
Download the YAML file containing the OpenShift secret for the token.
You can download the YAML file from the OpenShift Secret tab on your token’s Token Information page.
Create the authentication token secret for your OpenShift project using the YAML file that you downloaded:
oc create -f 1234567_myserviceaccount-secret.yaml
oc create -f 1234567_myserviceaccount-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Configure the secret for your OpenShift project using the following commands, replacing the secret name below with the name of your secret created in the previous step.
oc secrets link default 1234567-myserviceaccount-pull-secret --for=pull oc secrets link builder 1234567-myserviceaccount-pull-secret --for=pull
oc secrets link default 1234567-myserviceaccount-pull-secret --for=pull oc secrets link builder 1234567-myserviceaccount-pull-secret --for=pullCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. Importing the latest OpenShift imagestreams and templates for JBoss EAP XP Copy linkLink copied to clipboard!
Import the latest OpenShift imagestreams and templates for JBoss EAP XP.
OpenJDK 8 images and imagestreams on OpenShift are deprecated.
The images and imagestreams are still supported on OpenShift. However, no enhancements are made to these images and imagestreams and they might be removed in the future. Red Hat continues to provide full support and bug fixes OpenJDK 8 images and imagestreams under its standard support terms and conditions.
Procedure
Use one of the following commands to import the latest JDK 11 imagestreams and templates for the OpenShift image for JBoss EAP XP into your OpenShift project’s namespace.
Import JDK 11 imagestream:
oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap-xp3/jboss-eap-xp3-openjdk11-openshift.json
oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap-xp3/jboss-eap-xp3-openjdk11-openshift.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command imports the following imagestreams and templates:
- The JDK 11 builder imagestream: jboss-eap-xp3-openjdk11-openshift
- The JDK 11 runtime imagestream: jboss-eap-xp3-openjdk11-runtime-openshift
Import the JDK 11 templates:
oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap-xp3/templates/eap-xp3-basic-s2i.json
oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap-xp3/templates/eap-xp3-basic-s2i.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NoteThe JBoss EAP XP imagestreams and templates imported using the above command are only available within that OpenShift project.
If you have administrative access to the general
openshiftnamespace and want the imagestreams and templates to be accessible by all projects, add-n openshiftto theoc replaceline of the command. For example:... oc replace -n openshift --force -f \ ...
... oc replace -n openshift --force -f \ ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you want to import the imagestreams and templates into a different project, add the
-n PROJECT_NAMEto theoc replaceline of the command. For example:... oc replace -n PROJECT_NAME --force -f ...
... oc replace -n PROJECT_NAME --force -f ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you use the cluster-samples-operator, see the OpenShift documentation on configuring the cluster samples operator. See https://docs.openshift.com/container-platform/latest/openshift_images/configuring-samples-operator.html for details about configuring the cluster samples operator.
5.4. Deploying a JBoss EAP XP source-to-image (S2I) application on OpenShift Copy linkLink copied to clipboard!
Deploy a JBoss EAP XP source-to-image (S2I) application on OpenShift.
OpenJDK 8 images and imagestreams on OpenShift are deprecated.
The images and imagestreams are still supported on OpenShift. However, no enhancements are made to these images and imagestreams and they might be removed in the future. Red Hat continues to provide full support and bug fixes for OpenJDK 8 images and imagestreams under its standard support terms and conditions.
Prerequisites
-
Optional: A template can specify default values for many template parameters, and you might have to override some, or all, of the defaults. To see template information, including a list of parameters and any default values, use the command
oc describe template TEMPLATE_NAME.
Procedure
Create a new OpenShift application using the JBoss EAP XP image and your Java application’s source code. Use one of the provided JBoss EAP XP templates for S2I builds.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The template to use. The application image is tagged with the
latesttag. - 2
- The latest images streams and templates were imported into the project’s namespace, so you must specify the namespace of where to find the imagestream. This is usually the project’s name.
- 3
- URL to the repository containing the application source code.
- 4
- The Git repository reference to use for the source code. This can be a Git branch or tag reference.
- 5
- The directory within the source repository to build.
NoteA template can specify default values for many template parameters, and you might have to override some, or all, of the defaults. To see template information, including a list of parameters and any default values, use the command
oc describe template TEMPLATE_NAME.You might also want to configure environment variables when creating your new OpenShift application.
Retrieve the name of the build configurations.
oc get bc -o name
$ oc get bc -o nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the name of the build configurations from the previous step to view the Maven progress of the builds.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example, for the
microprofile-config, the following command shows the progress of the Maven builds.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. Completing post-deployment tasks for JBoss EAP XP source-to-image (S2I) application Copy linkLink copied to clipboard!
Depending on your application, you might need to complete some tasks after your OpenShift application has been built and deployed.
Examples of post-deployment tasks include the following:
- Exposing a service so that the application is viewable from outside of OpenShift.
- Scaling your application to a specific number of replicas.
Procedure
Get the service name of your application using the following command.
oc get service
$ oc get serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Expose the main service as a route so you can access your application from outside of OpenShift. For example, for the
microprofile-configquickstart, use the following command to expose the required service and port.NoteIf you used a template to create the application, the route might already exist. If it does, continue on to the next step.
oc expose service/eap-xp3-basic-app --port=8080
$ oc expose service/eap-xp3-basic-app --port=8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow Get the URL of the route.
oc get route
$ oc get routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Access the application in your web browser using the URL. The URL is the value of the
HOST/PORTfield from previous command’s output.NoteFor JBoss EAP XP 3.0.0 GA distribution, the Microprofile Config quickstart does not reply to HTTPS GET requests to the application’s root context. This enhancement is only available in the {JBossXPShortName101} GA distribution.
For example, to interact with the Microprofile Config application, the URL might be
http://HOST_PORT_Value/config/valuein your browser.If your application does not use the JBoss EAP root context, append the context of the application to the URL. For example, for the
microprofile-configquickstart, the URL might behttp://HOST_PORT_VALUE/microprofile-config/.Optionally, you can scale up the application instance by running the following command. This command increases the number of replicas to 3.
oc scale deploymentconfig DEPLOYMENTCONFIG_NAME --replicas=3
$ oc scale deploymentconfig DEPLOYMENTCONFIG_NAME --replicas=3Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example, for the
microprofile-configquickstart, use the following command to scale up the application.oc scale deploymentconfig/eap-xp3-basic-app --replicas=3
$ oc scale deploymentconfig/eap-xp3-basic-app --replicas=3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional Resources
For more information about JBoss EAP XP Quickstarts, see the Use the Quickstarts section in the Using MicroProfile in JBoss EAP guide.
Chapter 6. Capability trimming Copy linkLink copied to clipboard!
When building a bootable JAR, you can decide which JBoss EAP features and subsystems to include.
Capability trimming is supported only on OpenShift or when building a bootable JAR.
Additional resources
6.1. Available JBoss EAP layers Copy linkLink copied to clipboard!
Red Hat makes available a number of layers to customize provisioning of the JBoss EAP server in OpenShift or a bootable JAR.
Three layers are base layers that provide core functionality. The other layers are decorator layers that enhance the base layers with additional capabilities.
Most decorator layers can be used to build S2I images in JBoss EAP for OpenShift or to build a bootable JAR. A few layers do not support S2I images; the description of the layer notes this limitation.
Only the listed layers are supported. Layers not listed here are not supported.
6.1.1. Base layers Copy linkLink copied to clipboard!
Each base layer includes core functionality for a typical server user case.
datasources-web-server
This layer includes a servlet container and the ability to configure a datasource.
This layer does not include MicroProfile capabilities.
The following Jakarta EE specifications are supported in this layer:
- Jakarta JSON Processing 1.1
- Jakarta JSON Binding 1.0
- Jakarta Servlet 4.0
- Jakarta Expression Language 3.0
- Jakarta Server Pages 2.3
- Jakarta Standard Tag Library 1.2
- Jakarta Concurrency 1.1
- Jakarta Annotations 1.3
- Jakarta XML Binding 2.3
- Jakarta Debugging Support for Other Languages 1.0
- Jakarta Transaction 1.3
- Jakarta Connector API 1.7
jaxrs-server
This layer enhances the datasources-web-server layer with the following JBoss EAP subsystems:
-
jaxrs -
weld -
jpa
This layer also adds Infinispan-based second-level entity caching locally in the container.
The following MicroProfile capability is included in this layer:
- MicroProfile REST Client
The following Jakarta EE specifications are supported in this layer in addition to those supported in the datasources-web-server layer:
- Jakarta Contexts and Dependency Injection 2.0
- Jakarta Bean Validation 2.0
- Jakarta Interceptors 1.2
- Jakarta RESTful Web Services 2.1
- Jakarta Persistence 2.2
cloud-server
This layer enhances the jaxrs-server layer with the following JBoss EAP subsystems:
-
resource-adapters -
messaging-activemq(remote broker messaging, not embedded messaging)
This layer also adds the following observability features to the jaxrs-server layer:
- MicroProfile Health
- MicroProfile Metrics
- MicroProfile Config
- MicroProfile OpenTracing
The following Jakarta EE specification is supported in this layer in addition to those supported in the jaxrs-server layer:
- Jakarta Security 1.0
6.1.2. Decorator layers Copy linkLink copied to clipboard!
Decorator layers are not used alone. You can configure one or more decorator layers with a base layer to deliver additional functionality.
ejb-lite
This decorator layer adds a minimal Jakarta Enterprise Beans implementation to the provisioned server. The following support is not included in this layer:
- IIOP integration
- MDB instance pool
- Remote connector resource
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
Jakarta Enterprise Beans
This decorator layer extends the ejb-lite layer. This layer adds the following support to the provisioned server, in addition to the base functionality included in the ejb-lite layer:
- MDB instance pool
- Remote connector resource
Use this layer if you want to use message-driven beans (MDBs) or Jakarta Enterprise Beans remoting capabilities, or both. If you do not need these capabilities, use the ejb-lite layer.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
ejb-local-cache
This decorator layer adds local caching support for Jakarta Enterprise Beans to the provisioned server.
Dependencies: You can only include this layer if you have included the ejb-lite layer or the ejb layer.
This layer is not compatible with the ejb-dist-cache layer. If you include the ejb-dist-cache layer, you cannot include the ejb-local-cache layer. If you include both layers, the resulting build might include an unexpected Jakarta Enterprise Beans configuration.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
ejb-dist-cache
This decorator layer adds distributed caching support for Jakarta Enterprise Beans to the provisioned server.
Dependencies: You can only include this layer if you have included the ejb-lite layer or the ejb layer.
This layer is not compatible with the ejb-local-cache layer. If you include the ejb-dist-cache layer, you cannot include the ejb-local-cache layer. If you include both layers, the resulting build might result in an unexpected configuration.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
jdr
This decorator layer adds the JBoss Diagnostic Reporting (jdr) subsystem to gather diagnostic data when requesting support from Red Hat.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
Jakarta Persistence
This decorator layer adds persistence capabilities for a single-node server. Note that distributed caching only works if the servers are able to form a cluster.
The layer adds Hibernate libraries to the provisioned server, with the following support:
-
Configurations of the
jpasubsystem -
Configurations of the
infinispansubsystem - A local Hibernate cache container
This layer is not compatible with the jpa-distributed layer. If you include the jpa layer, you cannot include the jpa-distributed layer.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
jpa-distributed
This decorator layer adds persistence capabilities for servers operating in a cluster. The layer adds Hibernate libraries to the provisioned server, with the following support:
-
Configurations of the
jpasubsystem -
Configurations of the
infinispansubsystem - A local Hibernate cache container
- Invalidation and replication Hibernate cache containers
-
Configuration of the
jgroupssubsystem
This layer is not compatible with the jpa layer. If you include the jpa layer, you cannot include the jpa-distributed layer.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
Jakarta Server Faces
This decorator layer adds the jsf subsystem to the provisioned server.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
microprofile-platform
This decorator layer adds the following MicroProfile capabilities to the provisioned server:
- MicroProfile Config
- MicroProfile Fault Tolerance
- MicroProfile Health
- MicroProfile JWT
- MicroProfile Metrics
- MicroProfile OpenAPI
- MicroProfile OpenTracing
This layer includes MicroProfile capabilities that are also included in the observability layer. If you include this layer, you do not need to include the observability layer.
observability
This decorator layer adds the following observability features to the provisioned server:
- MicroProfile Health
- MicroProfile Metrics
- MicroProfile Config
- MicroProfile OpenTracing
This layer is built in to the cloud-server layer. You do not need to add this layer to the cloud-server layer.
remote-activemq
This decorator layer adds the ability to communicate with a remote ActiveMQ broker to the provisioned server, integrating messaging support.
The pooled connection factory configuration specifies guest as the value for the user and password attributes. You can use a CLI script to change these values at runtime.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
sso
This decorator layer adds Red Hat Single Sign-On integration to the provisioned server.
This layer should only be used when provisioning a server using S2I.
web-console
This decorator layer adds the management console to the provisioned server.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
web-clustering
This decorator layer adds support for distributable web applications by configuring a non-local Infinispan-based container web cache for data session handling suitable to clustering environments.
web-passivation
This decorator layer adds support for distributable web applications by configuring a local Infinispan-based container web cache for data session handling suitable to single node environments.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
webservices
This layer adds web services functionality to the provisioned server, supporting Jakarta web services deployments.
This layer is only supported when building a bootable JAR. This layer is not supported when using S2I.
Additional resources
Chapter 7. Enable MicroProfile application development for JBoss EAP on Red Hat CodeReady Studio Copy linkLink copied to clipboard!
If you want to incorporate MicroProfile capabilities in applications that you develop on CodeReady Studio, you must enable MicroProfile support for JBoss EAP in CodeReady Studio.
JBoss EAP expansion packs provide support for MicroProfile.
JBoss EAP expansion packs are not supported on JBoss EAP 7.2 and earlier.
Each version of the JBoss EAP expansion pack supports specific patches of JBoss EAP. For details, see the JBoss EAP expansion pack Support and Life Cycle Policies page.
The JBoss EAP XP Quickstarts for Openshift are provided as Technology Preview only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features.
7.1. Configuring CodeReady Studio to use MicroProfile capabilities Copy linkLink copied to clipboard!
To enable MicroProfile support on JBoss EAP, register a new runtime server for JBoss EAP XP, and then create the new JBoss EAP 7.4 server.
Give the server an appropriate name that helps you recognize that it supports MicroProfile capabilities.
This server uses a newly created JBoss EAP XP runtime that points to the runtime installed previously and uses the standalone-microprofile.xml configuration file.
If you set the Target runtime to 7.4 or a later runtime version in Red Hat CodeReady Studio, your project is compatible with the Jakarta EE 8 specification.
Prerequisites
Procedure
Set up the new server on the
New Serverdialog box.- In the Select server type list, select Red Hat JBoss Enterprise Application Platform 7.4.
- In the Server’s host name field, enter localhost.
- In the Server name field, enter JBoss EAP 7.4 XP.
- Click Next.
Configure the new server.
- In the Home directory field, if you do not want to use the default setting, specify a new directory; for example: home/myname/dev/microprofile/runtimes/jboss-eap-7.3.
- Make sure the Execution Environment is set to JavaSE-1.8.
- Optional: Change the values in the Server base directory and Configuration file fields.
- Click Finish.
Result
You are now ready to begin developing applications using MicroProfile capabilities, or to begin using the MicroProfile quickstarts for JBoss EAP.
7.2. Using MicroProfile quickstarts for CodeReady Studio Copy linkLink copied to clipboard!
Enabling the MicroProfile quickstarts makes the simple examples available to run and test on your installed server.
These examples illustrate the following MicroProfile capabilities.
- MicroProfile Config
- MicroProfile Fault Tolerance
- MicroProfile Health
- MicroProfile JWT
- MicroProfile Metrics
- MicroProfile OpenAPI
- MicroProfile OpenTracing
- MicroProfile REST Client
Procedure
-
Import the
pom.xmlfile from the Quickstart Parent Artifact. If the quickstart you are using requires environment variables, configure the environment variables.
Define environment variables on the launch configuration on the server Overview dialog box.
For example, the
microprofile-opentracingquickstart uses the following environment variables:-
JAEGER_REPORTER_LOG_SPANSset totrue -
JAEGER_SAMPLER_PARAMset to1 -
JAEGER_SAMPLER_TYPEset toconst
-
Additional resources
About JBoss Enterprise Application Platform expansion pack
Red Hat JBoss Enterprise Application Platform expansion pack Support and Life Cycle Policies
Chapter 8. The bootable JAR Copy linkLink copied to clipboard!
You can build and package a microservices application as a bootable JAR with the JBoss EAP JAR Maven plug-in. You can then run the application on a JBoss EAP bare-metal platform or a JBoss EAP OpenShift platform.
8.1. About the bootable JAR Copy linkLink copied to clipboard!
You can build and package a microservices application as a bootable JAR with the JBoss EAP JAR Maven plug-in.
A bootable JAR contains a server, a packaged application, and the runtime required to launch the server.
The JBoss EAP JAR Maven plug-in uses Galleon trimming capability to reduce the size and memory footprint of the server. Thus, you can configure the server according to your requirements, including only the Galleon layers that provide the capabilities that you need.
The JBoss EAP JAR Maven plug-in supports the execution of JBoss EAP CLI script files to customize your server configuration. A CLI script includes a list of CLI commands for configuring the server.
A bootable JAR is like a standard JBoss EAP server in the following ways:
- It supports JBoss EAP common management CLI commands.
- It can be managed using the JBoss EAP management console.
The following limitations exist when packaging a server in a bootable JAR:
- CLI management operations that require a server restart are not supported.
- The server cannot be restarted in admin-only mode, which is a mode that starts services related to server administration.
- If you shut down the server, updates that you applied to the server are lost.
Additionally, you can provision a hollow bootable JAR. This JAR contains only the server, so you can reuse the server to run a different application.
8.2. JBoss EAP Maven plug-in Copy linkLink copied to clipboard!
You can use the JBoss EAP JAR Maven plug-in to build an application as a bootable JAR.
You can retrieve the latest Maven plug-in version from the Maven repository, which is available at Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin.
In a Maven project, the src directory contains all the source files required to build your application. After the JBoss EAP JAR Maven plug-in builds the bootable JAR, the generated JAR is located in target/<application>-bootable.jar.
The JBoss EAP JAR Maven plug-in also provides the following functionality:
- Applies CLI script commands to the server.
-
Uses the
org.jboss.eap:wildfly-galleon-packGalleon feature pack and some of its layers for customizing the server configuration file. - Supports the addition of extra files into the packaged bootable JAR, such as a keystore file.
- Includes the capability to create a hollow bootable JAR; that is, a bootable JAR that does not contain an application.
After you use the JBoss EAP JAR Maven plug-in to create the bootable JAR, you can start the application by issuing the following command. Replace target/myapp-bootable.jar with the path to your bootable JAR. For example:
java -jar target/myapp-bootable.jar
$ java -jar target/myapp-bootable.jar
To get a list of supported bootable JAR startup commands, append --help to the end of the startup command. For example, java -jar target/myapp-bootable.jar --help.
8.3. Bootable JAR arguments Copy linkLink copied to clipboard!
View the arguments in the following table to learn about supported arguments for use with the bootable JAR.
| Argument | Description |
|---|---|
|
| Display the help message for the specified command and exit. |
|
| Argument specific to the hollow bootable JAR. Specifies the path to the WAR, JAR, EAR file or exploded directory that contains the application you want to deploy on a server. |
|
| Print the content of the generated Galleon configuration file. |
|
|
By default, the JVM settings are used to create a TEMP directory after the bootable JAR is started. You can use the |
|
| Runs the server with a security manager installed. |
|
|
Set system property |
|
|
Set system property |
|
| Specifies system properties that are set by the server at server runtime. The bootable JAR JVM does not set these system properties. |
|
| Loads system properties from a specified URL. |
|
| Set a security property. |
|
|
Set system property |
|
| Display the application server version and exit. |
8.4. Specifying Galleon layers for your bootable JAR server Copy linkLink copied to clipboard!
You can specify Galleon layers to build a custom configuration for your server. Additionally, you can specify Galleon layers that you want excluded from the server.
To reference a single feature pack, use the <feature-pack-location> element to specify its location. The following example specifies org.jboss.eap:wildfly-galleon-pack:3.0.0.GA-redhat-00001 in the <feature-pack-location> element of the Maven plug-in configuration file.
<configuration> <feature-pack-location>org.jboss.eap:wildfly-galleon-pack:3.0.0.GA-redhat-00001</feature-pack-location> </configuration>
<configuration>
<feature-pack-location>org.jboss.eap:wildfly-galleon-pack:3.0.0.GA-redhat-00001</feature-pack-location>
</configuration>
If you need to reference more than one feature pack, list them in the <feature-packs> element. The following example shows the addition of the Red Hat Single Sign-On feature pack to the <feature-packs> element:
You can combine Galleon layers from multiple feature packs to configure the bootable JAR server to include only the supported Galleon layers that provide the capabilities that you need.
On a bare-metal platform, if you do not specify Galleon layers in your configuration file then the provisioned server contains a configuration identical to that of a default standalone-microprofile.xml configuration.
On an OpenShift platform, after you have added the <cloud/> configuration element in the plug-in configuration and you choose not to specify Galleon layers in your configuration file, the provisioned server contains a configuration that is adjusted for the cloud environment and is similar to a default standalone-microprofile-ha.xml.
Prerequisites
- Maven is installed.
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack.
The examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version.
You must set these properties in your project. For example:
<properties>
<bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
<properties>
<bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
Procedure
- Identify the supported JBoss EAP Galleon layers that provide the capabilities that you need to run your application.
Reference a JBoss EAP feature pack location in the
<plugin>element of the Maven projectpom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack, as demonstrated in the following example. The following example also displays the inclusion of a single feature-pack, which includes thejaxrs-serverbase layer and thejpa-distributedlayer . Thejaxrs-serverbase layer provides additional support for the server.Copy to Clipboard Copied! Toggle word wrap Toggle overflow This example also shows the exclusion of the
jpalayer from the project.NoteIf you include the
jpa-distributedlayer in your project, you must exclude thejpalayer from thejaxrs-serverlayer. Thejpalayer configures a local infinispan hibernate cache, while thejpa-distributedlayer configures a remote infinispan hibernate cache.
8.5. Using a bootable JAR on a JBoss EAP bare-metal platform Copy linkLink copied to clipboard!
You can package an application as a bootable JAR on a JBoss EAP bare-metal platform.
A bootable JAR contains a server, a packaged application, and the runtime required to launch the server.
This procedure demonstrates packaging the MicroProfile Config microservices application as a bootable JAR with the JBoss EAP JAR Maven plug-in. See MicroProfile Config development.
You can use CLI scripts to configure the server during the packaging of the bootable JAR.
On building a web application that must be packaged inside a bootable JAR, you must specify war in the <packaging> element of your pom.xml file. For example:
<packaging>war</packaging>
<packaging>war</packaging>
This value is required to package the build application as a WAR file and not as the default JAR file.
In a Maven project that is used solely to build a hollow bootable JAR, set the packaging value to pom. For example:
<packaging>pom</packaging>
<packaging>pom</packaging>
You are not limited to using pom packaging when you build a hollow bootable JAR for a Maven project. You can create one by specifying true in the <hollow-jar> element for any type of packaging, such as war. See Creating a hollow bootable JAR on a JBoss EAP bare-metal platform.
Prerequisites
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack. - You have created a Maven project, set up a parent dependency, and added dependencies for creating an MicroProfile application. See MicroProfile Config development.
The examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version.
You must set these properties in your project. For example:
<properties>
<bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
<properties>
<bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
Procedure
Add the following content to the
<build>element of thepom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf you do not specify Galleon layers in your
pom.xmlfile then the bootable JAR server contains a configuration that is identical to astandalone-microprofile.xmlconfiguration.Package the application as a bootable JAR:
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Start the application:
NAME="foo" java -jar target/microprofile-config-bootable.jar
$ NAME="foo" java -jar target/microprofile-config-bootable.jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe example uses
NAMEas the environment variable, but you can choose to usejim, which is the default value.NoteTo view a list of supported bootable JAR arguments, append
--helpto the end of thejava -jar target/microprofile-config-bootable.jarcommand.Specify the following URL in your web browser to access the MicroProfile Config application:
http://localhost:8080/config/json
http://localhost:8080/config/jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verification: Test the application behaves properly by issuing the following command in your terminal:
curl http://localhost:8080/config/json
curl http://localhost:8080/config/jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is the expected output:
{"result":"Hello foo"}{"result":"Hello foo"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6. Creating a hollow bootable JAR on a JBoss EAP bare-metal platform Copy linkLink copied to clipboard!
You can package an application as a hollow bootable JAR on a JBoss EAP bare-metal platform.
A hollow bootable JAR contains only the JBoss EAP server. The hollow bootable JAR is packaged by the JBoss EAP JAR Maven plug-in. The application is provided at server runtime. The hollow bootable JAR is useful if you need to re-use the server configuration for a different application.
Prerequisites
- You have created a Maven project, set up a parent dependency, and added dependencies for creating an application. See MicroProfile Config development.
-
You have completed the
pom.xmlfile configuration steps outlined in Using a bootable JAR on a JBoss EAP bare-metal platform. -
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack.
The example shown in the procedure specifies ${jboss.xp.galleon.feature.pack.version} for the Galleon feature pack version, but you must set the property in your project. For example:
<properties>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
<properties>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
Procedure
-
To build a hollow bootable JAR, you must set the
<hollow-jar>plug-in configuration element to true in the projectpom.xmlfile. For example:
By specifying true in the <hollow-jar> element, the JBoss EAP JAR Maven plug-in does not include an application in the JAR.
Build the hollow bootable JAR:
mvn clean package
$ mvn clean packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the hollow bootable JAR:
java -jar target/microprofile-config-bootable.jar --deployment=target/microprofile-config.war
$ java -jar target/microprofile-config-bootable.jar --deployment=target/microprofile-config.warCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantTo specify the path to the WAR file that you want to deploy on the server, use the following argument, where
<PATH_NAME>is the path to your deployment.--deployment=<PATH_NAME>
--deployment=<PATH_NAME>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Access the application:
curl http://localhost:8080/microprofile-config/config/json
$ curl http://localhost:8080/microprofile-config/config/jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteTo register your web application in the root directory, name the application
ROOT.war.
8.7. CLI scripts Copy linkLink copied to clipboard!
You can create CLI scripts to configure the server during the packaging of the bootable JAR.
A CLI script is a text file that contains a sequence of CLI commands that you can use to apply additional server configurations. For example, you can create a script to add a new logger to the logging subsystem.
You can also specify more complex operations in a CLI script. For example, you can group security management operations into a single command to enable HTTP authentication for the management HTTP endpoint.
You must define CLI scripts in the <cli-session> element of the plug-in configuration before you package an application as a bootable JAR. This ensures the server configuration settings persist after packaging the bootable JAR.
Although you can combine predefined Galleon layers to configure a server that deploys your application, limitations do exist. For example, you cannot enable the HTTPS undertow listener using Galleon layers when packaging the bootable JAR. Instead, you must use a CLI script.
You must define the CLI scripts in the <cli-session> element of the pom.xml file. The following table shows types of CLI session attributes:
| Argument | Description |
|---|---|
|
| List of paths to script files. |
|
|
Optional attribute that specifies a path to a properties file. This file lists Java properties that scripts can reference by using the |
|
|
Optional attribute that contains a boolean value. Indicates if system properties or expressions are resolved before sending the operation requests to the server. Value is |
-
CLI scripts are started in the order that they are defined in the
<cli-session>element of thepom.xmlfile. - The JBoss EAP JAR Maven plug-in starts the embedded server for each CLI session. Thus, your CLI script does not have to start or stop the embedded server.
8.8. Using a bootable JAR on a JBoss EAP OpenShift platform Copy linkLink copied to clipboard!
After you packaged an application as a bootable JAR, you can run the application on a JBoss EAP OpenShift platform.
On OpenShift, you cannot use the EAP Operator automated transaction recovery feature with your bootable JAR. A fix for this technical limitation is planned for a future JBoss EAP XP 3.0.0 patch release.
Prerequisites
- You have created a Maven project for MicroProfile Config development.
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP 3 and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack.
The examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version.
You must set these properties in your project. For example:
<properties>
<bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
<properties>
<bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version>
<jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version>
</properties>
Procedure
Add the following content to the
<build>element of thepom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteYou must include the
<cloud/>element in the<configuration>element of the plug-in configuration, so the JBoss EAP Maven JAR plug-in can identify that you choose the OpenShift platform.Package the application:
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Log in to your OpenShift instance using the
oc logincommand. Create a new project in OpenShift. For example:
oc new-project bootable-jar-project
$ oc new-project bootable-jar-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the following
occommands to create an application image:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Creates an openshift sub-directory in the target directory. The packaged application is copied into the created sub-directory.
- 2
- Imports the latest OpenJDK 11 imagestream tag and image information into the OpenShift project.
- 3
- Creates a build configuration based on the microprofile-config-app directory and the OpenJDK 11 imagestream.
- 4
- Uses the
target/openshiftsub-directory as the binary input to build the application.
NoteOpenShift applies a set of CLI script commands to the bootable JAR configuration file to adjust it to the cloud environment. You can access this script by opening the
bootable-jar-build-artifacts/generated-cli-script.txtfile in the Maven project/target directory.Verification:
View a list of OpenShift pods available and check the pods build statuses by issuing the following command:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the built application image:
oc get is microprofile-config-app
$ oc get is microprofile-config-appCopy to Clipboard Copied! Toggle word wrap Toggle overflow The output shows the built application image details, such as name and image repository, tag, and so on. For the example in this procedure, the imagestream name and tag output displays
microprofile-config-app:latest.Deploy the application:
oc new-app microprofile-config-app oc expose svc/microprofile-config-app
$ oc new-app microprofile-config-app $ oc expose svc/microprofile-config-appCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantTo provide system properties to the bootable JAR, you must use the
JAVA_OPTS_APPENDenvironment variable. The following example demonstrates usage of theJAVA_OPTS_APPENDenvironment variable:oc new-app <_IMAGESTREAM_> -e JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time -Dwildfly.statistics-enabled=true"
$ oc new-app <_IMAGESTREAM_> -e JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time -Dwildfly.statistics-enabled=true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow A new application is created and started. The application configuration is exposed as a new service.
Verification: Test the application behaves properly by issuing the following command in your terminal:
curl http://$(oc get route microprofile-config-app --template='{{ .spec.host }}')/config/json$ curl http://$(oc get route microprofile-config-app --template='{{ .spec.host }}')/config/jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output:
{"result":"Hello jim"}{"result":"Hello jim"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.9. Configure the bootable JAR for OpenShift Copy linkLink copied to clipboard!
Before using your bootable JAR, you can configure JVM settings to ensure that your standalone server operates correctly on JBoss EAP for OpenShift.
Use the JAVA_OPTS_APPEND environment variable to configure JVM settings. Use the JAVA_ARGS command to provide arguments to the bootable JAR.
You can use environment variables to set values for properties. For example, you can use the JAVA_OPTS_APPEND environment variable to set the -Dwildfly.statistics-enabled property to true:
JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time -Dwildfly.statistics-enabled=true"
JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time -Dwildfly.statistics-enabled=true"
Statistics are now enabled for your server.
Use the JAVA_ARGS environment variable, if you need to provide arguments to the bootable JAR.
JBoss EAP for OpenShift provides a JDK 11 image. To run the application associated with your bootable JAR, you must first import the latest OpenJDK 11 imagestream tag and image information into your OpenShift project. You can then use environment variables to configure the JVM in the imported image.
You can apply the same configuration options for configuring the JVM used for JBoss EAP for OpenShift S2I image, but with the following differences:
-
Optional: The
-Xlogcapability is not available, but you can set garbage collection logging by enabling-Xlog:gc. For example:JAVA_OPTS_APPEND="-Xlog:gc*:file=/tmp/gc.log:time". -
To increase initial metaspace size, you can set the
GC_METASPACE_SIZEenvironment variable. For best metadata capacity performance, set the value to96. -
The default value for
GC_MAX_METASPACE_SIZEis set as100, but for best metadata capacity after a garbage collection, you must set it to at least256. -
For better random file generation, use the
JAVA_OPTS_APPENDenvironment variable to setjava.security.egdproperty as-Djava.security.egd=file:/dev/urandom.
These configurations improve the memory settings and garbage collection capability of JVM when running on your imported OpenJDK 11 image.
8.10. Using a ConfigMap in your application on OpenShift Copy linkLink copied to clipboard!
For OpenShift, you can use a deployment controller (dc) to mount the configmap into the pods used to run the application.
A ConfigMap is an OpenShift resource that is used to store non-confidential data in key-value pairs.
After you specify the microprofile-platform Galleon layer to add microprofile-config-smallrye subsystem and any extensions to the server configuration file, you can use a CLI script to add a new ConfigSource to the server configuration. You can save CLI scripts in an accessible directory, such as the /scripts directory, in the root directory of your Maven project.
MicroProfile Config functionality is implemented in JBoss EAP using the SmallRye Config component and is provided by the microprofile-config-smallrye subsystem. This subsystem is included in the microprofile-platform Galleon layer.
Prerequisites
- You have installed Maven.
- You have configured the JBoss EAP Maven repository.
- You have packaged an application as a bootable JAR and you can run the application on a JBoss EAP OpenShift platform. For information about building an application as a bootable JAR on an OpenShift platform, see Using a bootable JAR on a JBoss EAP OpenShift platform.
Procedure
Create a directory named
scriptsat the root directory of your project. For example:mkdir scripts
$ mkdir scriptsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a
cli.propertiesfile and save the file in the/scriptsdirectory. Define theconfig.pathand theconfig.ordinalsystem properties in this file. For example:config.path=/etc/config config.ordinal=200
config.path=/etc/config config.ordinal=200Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a CLI script, such as
mp-config.cli, and save it in an accessible directory in the bootable JAR, such as the/scriptsdirectory. The following example shows the contents of themp-config.cliscript:config map
# config map /subsystem=microprofile-config-smallrye/config-source=os-map:add(dir={path=${config.path}}, ordinal=${config.ordinal})Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
mp-config.cliCLI script creates a newConfigSource, to which ordinal and path values are retrieved from a properties file.-
Save the script in the
/scriptsdirectory, which is located at the root directory of the project. Add the following configuration extract to the existing plug-in
<configuration>element:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Package the application:
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Log in to your OpenShift instance using the
oc logincommand. Optional: If you have not previously created a
target/openshiftsubdirectory, you must create the suddirectory by issuing the following command:mkdir target/openshift
$ mkdir target/openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy the packaged application into the created subdirectory.
cp target/microprofile-config-bootable.jar target/openshift
$ cp target/microprofile-config-bootable.jar target/openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the
target/openshiftsubdirectory as the binary input to build the application:oc start-build microprofile-config-app --from-dir target/openshift
$ oc start-build microprofile-config-app --from-dir target/openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteOpenShift applies a set of CLI script commands to the bootable JAR configuration file to enable it for the cloud environment. You can access this script by opening the
bootable-jar-build-artifacts/generated-cli-script.txtfile in the Maven project/targetdirectory.Create a
ConfigMap. For example:oc create configmap microprofile-config-map --from-literal=name="Name comes from Openshift ConfigMap"
$ oc create configmap microprofile-config-map --from-literal=name="Name comes from Openshift ConfigMap"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Mount the
ConfigMapinto the application with the dc. For example:oc set volume deployments/microprofile-config-app --add --name=config-volume \ --mount-path=/etc/config \ --type=configmap \ --configmap-name=microprofile-config-map
$ oc set volume deployments/microprofile-config-app --add --name=config-volume \ --mount-path=/etc/config \ --type=configmap \ --configmap-name=microprofile-config-mapCopy to Clipboard Copied! Toggle word wrap Toggle overflow After executing the
oc set volumecommand, the application is re-deployed with the new configuration settings.Test the output:
curl http://$(oc get route microprofile-config-app --template='{{ .spec.host }}')/config/json$ curl http://$(oc get route microprofile-config-app --template='{{ .spec.host }}')/config/jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow The following is the expected output:
{"result":"Hello Name comes from Openshift ConfigMap"}{"result":"Hello Name comes from Openshift ConfigMap"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.11. Creating a bootable JAR Maven project Copy linkLink copied to clipboard!
Follow the steps in the procedure to create an example Maven project. You must create a Maven project before you can perform the following procedures:
- Enabling JSON logging for your bootable JAR
- Enabling web session data storage for multiple bootable JAR instances
- Enabling HTTP authentication for bootable JAR with a CLI script
- Securing your JBoss EAP bootable JAR application with Red Hat Single Sign-On
In the project pom.xml file, you can configure Maven to retrieve the project artifacts required to build your bootable JAR.
Procedure
Set up the Maven project:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where GROUP_ID is the
groupIdof your project and ARTIFACT_ID is theartifactIdof your project.In the
pom.xmlfile, configure Maven to retrieve the JBoss EAP BOM file from a remote repository.Copy to Clipboard Copied! Toggle word wrap Toggle overflow To configure Maven to automatically manage versions for the Jakarta EE artifacts in the
jboss-eap-jakartaee8BOM, add the BOM to the<dependencyManagement>section of the projectpom.xmlfile. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the servlet API artifact, which is managed by the BOM, to the
<dependency>section of the projectpom.xmlfile, as shown in the following example:<dependency> <groupId>org.jboss.spec.javax.servlet</groupId> <artifactId>jboss-servlet-api_4.0_spec</artifactId> <scope>provided</scope> </dependency><dependency> <groupId>org.jboss.spec.javax.servlet</groupId> <artifactId>jboss-servlet-api_4.0_spec</artifactId> <scope>provided</scope> </dependency>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.12. Enabling JSON logging for your bootable JAR Copy linkLink copied to clipboard!
You can enable JSON logging for your bootable JAR by configuring the server logging configuration with a CLI script. When you enable JSON logging, you can use the JSON formatter to view log messages in JSON format.
The example in this procedure shows you how to enable JSON logging for your bootable JAR on a bare-metal platform and an OpenShift platform.
Prerequisites
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the minor version of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack. You have created a Maven project, set up a parent dependency, and added dependencies for creating an application. See Creating a bootable JAR Maven project.
ImportantIn the Maven archetype of your Maven project, you must specify the groupID and artifactID that are specific to your project. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version.
You must set these properties in your project. For example:
<properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> </properties><properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> </properties>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Procedure
Add the JBoss Logging and Jakarta RESTful Web Services dependencies, which are managed by the BOM, to the
<dependencies>section of the projectpom.xmlfile. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following content to the
<build>element of thepom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the directory to store Java files:
mkdir -p APPLICATION_ROOT/src/main/java/com/example/logging/
$ mkdir -p APPLICATION_ROOT/src/main/java/com/example/logging/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the directory containing thepom.xmlconfiguration file for the application.Create a Java file
RestApplication.javawith the following content and save the file in theAPPLICATION_ROOT/src/main/java/com/example/logging/directory:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Java file
HelloWorldEndpoint.javawith the following content and save the file in theAPPLICATION_ROOT/src/main/java/com/example/logging/directory:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a CLI script, such as
logging.cli, and save it in an accessible directory in the bootable JAR, such as theAPPLICATION_ROOT/scriptsdirectory, whereAPPLICATION_ROOTis the root directory of your Maven project. The script must contain the following commands:/subsystem=logging/logger=com.example.logging:add(level=ALL) /subsystem=logging/json-formatter=json-formatter:add(exception-output-type=formatted, pretty-print=false, meta-data={version="1"}, key-overrides={timestamp="@timestamp"}) /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level,value=ALL) /subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=json-formatter)/subsystem=logging/logger=com.example.logging:add(level=ALL) /subsystem=logging/json-formatter=json-formatter:add(exception-output-type=formatted, pretty-print=false, meta-data={version="1"}, key-overrides={timestamp="@timestamp"}) /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level,value=ALL) /subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=json-formatter)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following configuration extract to the plug-in
<configuration>element:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This example shows the
logging.cliCLI script, which modifies the server logging configuration file to enable JSON logging for your application.Package the application as a bootable JAR.
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: To run the application on a JBoss EAP bare-metal platform, follow the steps outlined in Using a bootable JAR on a JBoss EAP bare-metal platform, but with the following difference:
Start the application:
mvn wildfly-jar:run
mvn wildfly-jar:runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verification: You can access the application by specifying the following URL in your browser: http://127.0.0.1:8080/hello.
Expected output: You can view the JSON-formatted logs, including the
com.example.logging.HelloWorldEndpointdebug trace, in the application console.
Optional: To run the application on a JBoss EAP OpenShift platform, complete the following steps:
Add the
<cloud/>element to the plug-in configuration. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Rebuild the application:
mvn clean package
$ mvn clean packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Log in to your OpenShift instance using the
oc logincommand. Create a new project in OpenShift. For example:
oc new-project bootable-jar-project
$ oc new-project bootable-jar-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the following
occommands to create an application image:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Creates the
target/openshiftsubdirectory. The packaged application is copied into theopenshiftsubdirectory. - 2
- Imports the latest OpenJDK 11 imagestream tag and image information into the OpenShift project.
- 3
- Creates a build configuration based on the logging directory and the OpenJDK 11 imagestream.
- 4
- Uses the
target/openshiftsubdirectory as the binary input to build the application.
Deploy the application:
oc new-app logging oc expose svc/logging
$ oc new-app logging $ oc expose svc/loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow Get the URL of the route.
oc get route logging --template='{{ .spec.host }}'$ oc get route logging --template='{{ .spec.host }}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Access the application in your web browser using the URL returned from the previous command. For example:
http://ROUTE_NAME/hello
http://ROUTE_NAME/helloCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verification: Issue the following command to view a list of OpenShift pods available, and to check the pods build statuses:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Access a running pod log of your application. Where
APP_POD_NAMEis the name of the running pod logging application.oc logs APP_POD_NAME
$ oc logs APP_POD_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected outcome: The pod log is in JSON format and includes the
com.example.logging.HelloWorldEndpointdebug trace.
8.13. Enabling web session data storage for multiple bootable JAR instances Copy linkLink copied to clipboard!
You can build and package a web-clustering application as a bootable JAR.
Prerequisites
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack. You have created a Maven project, set up a parent dependency, and added dependencies for creating a web-clustering application. See Creating a bootable JAR Maven project.
ImportantWhen setting up the Maven project, you must specify values in the Maven archetype configuration. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version.
You must set these properties in your project. For example:
<properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> </properties><properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> </properties>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Procedure
Add the following content to the
<build>element of thepom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThis example makes use of the
web-clusteringGalleon layer to enable web session sharing.Update the
web.xmlfile in thesrc/main/webapp/WEB-INFdirectory with the following configuration:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
<distributable/>tag indicates that this servlet can be distributed across multiple servers.Create the directory to store Java files:
mkdir -p APPLICATION_ROOT
$ mkdir -p APPLICATION_ROOT /src/main/java/com/example/webclustering/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the directory containing thepom.xmlconfiguration file for the application.Create a Java file
MyServlet.javawith the following content and save the file in theAPPLICATION_ROOT/src/main/java/com/example/webclustering/directory.Copy to Clipboard Copied! Toggle word wrap Toggle overflow The content in
MyServlet.javadefines the endpoint to which a client sends an HTTP request.Create a Java file
User.javawith the following content and save the file in theAPPLICATION_ROOT/src/main/java/com/example/webclustering/directory.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Package the application:
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: To run the application on a JBoss EAP bare-metal platform, follow the steps outlined in Using a bootable JAR on a JBoss EAP bare-metal platform, but with the following difference:
On a JBoss EAP bare-metal platform, you can use the
java -jarcommand to run multiple bootable JAR instances, as demonstrated in the following examples:java -jar target/web-clustering-bootable.jar -Djboss.node.name=node1 java -jar target/web-clustering-bootable.jar -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=10
$ java -jar target/web-clustering-bootable.jar -Djboss.node.name=node1 $ java -jar target/web-clustering-bootable.jar -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=10Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verification: You can access the application on the node 1 instance: http://127.0.0.1:8080/clustering. Note the user session ID and the user-creation time.
After you kill this instance, you can access the node 2 instance: http://127.0.0.1:8090/clustering. The user must match the session ID and the user-creation time of the node 1 instance.
Optional: To run the application on a JBoss EAP OpenShift platform, follow the steps outlined in Using a bootable JAR on a JBoss EAP OpenShift platform, but complete the following steps:
Add the
<cloud/>element to the plug-in configuration. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Rebuild the application:
mvn clean package
$ mvn clean packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Log in to your OpenShift instance using the
oc logincommand. Create a new project in OpenShift. For example:
oc new-project bootable-jar-project
$ oc new-project bootable-jar-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow To run a web-clustering application on a JBoss EAP OpenShift platform, authorization access must be granted for the service account that the pod is running in. The service account can then access the Kubernetes REST API. The following example shows authorization access being granted to a service account:
oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
$ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the following
occommands to create an application image:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Creates the
target/openshiftsub-directory. The packaged application is copied into theopenshiftsub-directory. - 2
- Imports the latest OpenJDK 11 imagestream tag and image information into the OpenShift project.
- 3
- Creates a build configuration based on the web-clustering directory and the OpenJDK 11 imagestream.
- 4
- Uses the
target/openshiftsub-directory as the binary input to build the application.
Deploy the application:
oc new-app web-clustering -e KUBERNETES_NAMESPACE=$(oc project -q) oc expose svc/web-clustering
$ oc new-app web-clustering -e KUBERNETES_NAMESPACE=$(oc project -q) $ oc expose svc/web-clusteringCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantYou must use the
KUBERNETES_NAMESPACEenvironment variable to view other pods in the current OpenShift namespace; otherwise, the server attempts to retrieve the pods from thedefaultnamespace.Get the URL of the route.
oc get route web-clustering --template='{{ .spec.host }}'$ oc get route web-clustering --template='{{ .spec.host }}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Access the application in your web browser using the URL returned from the previous command. For example:
http://ROUTE_NAME/clustering
http://ROUTE_NAME/clusteringCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note the user session ID and user creation time.
Scale the application to two pods:
oc scale --replicas=2 deployments web-clustering
$ oc scale --replicas=2 deployments web-clusteringCopy to Clipboard Copied! Toggle word wrap Toggle overflow Issue the following command to view a list of OpenShift pods available, and to check the pods build statuses:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Kill the oldest pod using the
oc delete pod web-clustering-POD_NAMEcommand, where POD_NAME is the name of your oldest pod. Access the application again:
http://ROUTE_NAME/clustering
http://ROUTE_NAME/clusteringCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected outcome: The session ID and the creation time generated by the new pod match those of the of the terminated pod. This indicates that web session data storage is enabled.
8.14. Enabling HTTP authentication for bootable JAR with a CLI script Copy linkLink copied to clipboard!
You can enable HTTP authentication for the bootable JAR with a CLI script. This script adds a security realm and a security domain to your server.
Prerequisites
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack. You have created a Maven project, set up a parent dependency, and added dependencies for creating an application that requires HTTP authentication. See Creating a bootable JAR Maven project.
ImportantWhen setting up the Maven project, you must specify HTTP authentication values in the Maven archetype configuration. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version.
You must set these properties in your project. For example:
<properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> </properties><properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> </properties>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Procedure
Add the following content to the
<build>element of thepom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The example shows the inclusion of the
datasources-web-serverGalleon layer that contains theelytronsubsystem.Update the
web.xmlfile in thesrc/main/webapp/WEB-INFdirectory. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the directory to store Java files:
mkdir -p APPLICATION_ROOT/src/main/java/com/example/authentication/
$ mkdir -p APPLICATION_ROOT/src/main/java/com/example/authentication/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the root directory of your Maven project.Create a Java file
TestServlet.javawith the following content and save the file in theAPPLICATION_ROOT/src/main/java/com/example/authentication/directory.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a CLI script, such as
authentication.cli, and save it in an accessible directory in the bootable JAR, such as theAPPLICATION_ROOT/scriptsdirectory. The script must contain the following commands:/subsystem=elytron/properties-realm=bootable-realm:add(users-properties={relative-to=jboss.server.config.dir, path=bootable-users.properties, plain-text=true}, groups-properties={relative-to=jboss.server.config.dir, path=bootable-groups.properties}) /subsystem=elytron/security-domain=BootableDomain:add(default-realm=bootable-realm, permission-mapper=default-permission-mapper, realms=[{realm=bootable-realm, role-decoder=groups-to-roles}]) /subsystem=undertow/application-security-domain=other:write-attribute(name=security-domain, value=BootableDomain)/subsystem=elytron/properties-realm=bootable-realm:add(users-properties={relative-to=jboss.server.config.dir, path=bootable-users.properties, plain-text=true}, groups-properties={relative-to=jboss.server.config.dir, path=bootable-groups.properties}) /subsystem=elytron/security-domain=BootableDomain:add(default-realm=bootable-realm, permission-mapper=default-permission-mapper, realms=[{realm=bootable-realm, role-decoder=groups-to-roles}]) /subsystem=undertow/application-security-domain=other:write-attribute(name=security-domain, value=BootableDomain)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following configuration extract to the plug-in
<configuration>element:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This example shows the
authentication.cliCLI script, which configures the defaultundertowsecurity domain to the security domain defined for your server.In the root directory of your Maven project create a directory to store the properties files that the JBoss EAP JAR Maven plug-in adds to the bootable JAR:
mkdir -p APPLICATION_ROOT/extra-content/standalone/configuration/
$ mkdir -p APPLICATION_ROOT/extra-content/standalone/configuration/Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where
APPLICATION_ROOTis the directory containing thepom.xmlconfiguration file for the application.This directory stores files such as
bootable-users.propertiesandbootable-groups.propertiesfiles.The
bootable-users.propertiesfile contains the following content:testuser=bootable_password
testuser=bootable_passwordCopy to Clipboard Copied! Toggle word wrap Toggle overflow The
bootable-groups.propertiesfile contains the following content:testuser=Users
testuser=UsersCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following
extra-content-content-dirselement to the existing<configuration>element:<extra-server-content-dirs> <extra-content>extra-content</extra-content> </extra-server-content-dirs><extra-server-content-dirs> <extra-content>extra-content</extra-content> </extra-server-content-dirs>Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
extra-contentdirectory contains the properties files.Package the application as a bootable JAR.
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Start the application:
mvn wildfly-jar:run
mvn wildfly-jar:runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Call the servlet, but do not specify credentials:
curl -v http://localhost:8080/hello
curl -v http://localhost:8080/helloCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output:
HTTP/1.1 401 Unauthorized ... WWW-Authenticate: Basic realm="Example Realm"
HTTP/1.1 401 Unauthorized ... WWW-Authenticate: Basic realm="Example Realm"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Call the server and specify your credentials. For example:
curl -v -u testuser:bootable_password http://localhost:8080/hello
$ curl -v -u testuser:bootable_password http://localhost:8080/helloCopy to Clipboard Copied! Toggle word wrap Toggle overflow A HTTP 200 status is returned that indicates HTTP authentication is enabled for your bootable JAR. For example:
HTTP/1.1 200 OK .... Hello testuser
HTTP/1.1 200 OK .... Hello testuserCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.15. Securing your JBoss EAP bootable JAR application with Red Hat Single Sign-On Copy linkLink copied to clipboard!
You can use the Galleon keycloak-client-oidc layer to install a version of a server that is provisioned with Red Hat Single Sign-On 7.4 OpenID Connect client adapters.
The keycloak-client-oidc layer provides Red Hat Single Sign-On OpenID Connect client adapters to your Maven project. This layer is included with the keycloak-adapter-galleon-pack Red Hat Single Sign-On feature pack.
You can add the keycloak-adapter-galleon-pack feature pack to your JBoss EAP Maven plug-in configuration and then add the keycloak-client-oidc. You can view Red Hat Single Sign-On client adapters that are compatible with JBoss EAP by visiting the Supported Configurations: Red Hat Single Sign-On 7.4 web page.
The example in this procedure shows you how to secure a JBoss EAP bootable JAR by using JBoss EAP features provided by the keycloak-client-oidc layer.
Prerequisites
-
You have checked the latest Maven plug-in version, such as
MAVEN_PLUGIN_VERSION.X.GA.Final-redhat-00001, where MAVEN_PLUGIN_VERSION is the major version and X is the microversion. See Index of /ga/org/wildfly/plugins/wildfly-jar-maven-plugin. -
You have checked the latest Galleon feature pack version, such as
3.0.X.GA-redhat-BUILD_NUMBER, where X is the microversion of JBoss EAP XP and BUILD_NUMBER is the build number of the Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/eap/wildfly-galleon-pack. -
You have checked the latest Red Hat Single Sign-On Galleon feature pack version, such as
org.jboss.sso:keycloak-adapter-galleon-pack:9.0.X:redhat-BUILD_NUMBER, whereXis the microversion of Red Hat Single Sign-On that depends on the Red Hat Single Sign-On server release used to secure the application, andBUILD_NUMBERis the build number of the Red Hat Single Sign-On Galleon feature pack. Both X and BUILD_NUMBER can evolve during the JBoss EAP XP 3.0.0 product life cycle. See Index of /ga/org/jboss/sso/keycloak-adapter-galleon-pack. - You have created a Maven project, set up a parent dependency, and added dependencies for creating an application that you want secured with Red Hat Single Sign-On. See Creating a bootable JAR Maven project.
- You have a Red Hat Single Sign-On server that is running on port 8090. See Starting the Red Hat Single Sign-On server.
You have logged in to the Red Hat Single Sign-On Admin Console and created the following metadata:
-
A realm named
demo. -
A role named
Users. -
A user and password. You must assign a
Usersrole to the user. A
public-clientweb application with a Root URL. The example in the procedure, definessimple-webappas the web application andhttp://localhost:8080/simple-webapp/securedas the Root URL.ImportantWhen setting up the Maven project, you must specify values for the application that you want to secure with Red Hat Single Sign-On in the Maven archetype. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe examples shown in the procedure specify the following properties:
-
${bootable.jar.maven.plugin.version}for the Maven plug-in version. -
${jboss.xp.galleon.feature.pack.version}for the Galleon feature pack version. -
${keycloak.feature.pack.version}for the Red Hat Single Sign-On feature pack version.
You must set these properties in your project. For example:
<properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> <keycloak.feature.pack.version>9.0.10.redhat-00001</keycloak.feature.pack.version> </properties><properties> <bootable.jar.maven.plugin.version>4.0.3.Final-redhat-00001</bootable.jar.maven.plugin.version> <jboss.xp.galleon.feature.pack.version>3.0.0.GA-redhat-00001</jboss.xp.galleon.feature.pack.version> <keycloak.feature.pack.version>9.0.10.redhat-00001</keycloak.feature.pack.version> </properties>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
-
A realm named
Procedure
Add the following content to the
<build>element of thepom.xmlfile. You must specify the latest version of any Maven plug-in and the latest version of theorg.jboss.eap:wildfly-galleon-packGalleon feature pack. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The Maven plug-in provisions subsystems and modules that are required for deploying the web application.
The
keycloak-client-oidclayer provides Red Hat Single Sign-On OpenID Connect client adapters to your project by using thekeycloaksubsystem and its dependencies to activate support for Red Hat Single Sign-On authentication. Red Hat Single Sign-On client adapters are libraries that secure applications and services with Red Hat Single Sign-On.In the project
pom.xmlfile, set the<context-root>tofalsein your plug-in configuration. This registers the application in thesimple-webappresource path. By default, the WAR file is registered under the root-context path.<configuration> ... <context-root>false</context-root> ... </configuration><configuration> ... <context-root>false</context-root> ... </configuration>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a CLI script, such as
configure-oidc.cliand save it in an accessible directory in the bootable JAR, such as theAPPLICATION_ROOT/scriptsdirectory, where APPLICATION_ROOT is the root directory of your Maven project. The script must contain commands similar to the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This script example defines the
secure-deployment=simple-webapp.warresource in thekeycloaksubsystem. Thesimple-webapp.warresource is the name of the WAR file that is deployed in the bootable JAR.In the project
pom.xmlfile, add the following configuration extract to the existing plug-in<configuration>element:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update the
web.xmlfile in thesrc/main/webapp/WEB-INFdirectory. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: Alternatively to steps 7 through 9, you can embed the server configuration in the web application by adding the
keycloak.jsondescriptor to theWEB-INFdirectory of the web application. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow You must then set the
<auth-method>of the web application toKEYCLOAK. The following example code illustrates how to set the<auth-method>:<login-config> <auth-method>KEYCLOAK</auth-method> <realm-name>Simple Realm</realm-name> </login-config><login-config> <auth-method>KEYCLOAK</auth-method> <realm-name>Simple Realm</realm-name> </login-config>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Java file named
SecuredServlet.javawith the following content and save the file in theAPPLICATION_ROOT/src/main/java/com/example/securedservlet/directory.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Package the application as a bootable JAR.
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow Start the application. The following example starts the
simple-webappweb application from its specified bootable JAR path:java -jar target/simple-webapp-bootable.jar
$ java -jar target/simple-webapp-bootable.jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow Specify the following URL in your web browser to access the webpage secured with Red Hat Single Sign-On. The following example shows the URL for the secured
simple-webappweb application:http://localhost:8080/simple-webapp/secured
http://localhost:8080/simple-webapp/securedCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Log in as a user from your Red Hat Single Sign-On realm.
Verification: Check that the webpage displays the following output:
Current Principal '<principal id>'
Current Principal '<principal id>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.16. Packaging a bootable JAR in dev mode Copy linkLink copied to clipboard!
The JBoss EAP JAR Maven plug-in dev goal provides dev mode, Development Mode, which you can use to enhance your application development process.
In dev mode, you do not need to rebuild the bootable JAR after you make changes to your application.
The workflow in this procedure demonstrates using dev mode to configure a bootable JAR.
Prerequisites
- Maven is installed.
- You have created a Maven project, set up a parent dependency, and added dependencies for creating an MicroProfile application. See MicroProfile Config development.
-
You have specified the JBoss EAP JAR Maven plug-in in your Maven project
pom.xmlfile.
Procedure
Build and start the bootable JAR in Development Mode:
mvn wildfly-jar:dev
$ mvn wildfly-jar:devCopy to Clipboard Copied! Toggle word wrap Toggle overflow In
devmode, the server deployment scanner is configured to monitor thetarget/deploymentsdirectory.Prompt the JBoss EAP Maven Plug-in to build and copy your application to the
target/deploymentsdirectory with the following command:mvn package -Ddev
$ mvn package -DdevCopy to Clipboard Copied! Toggle word wrap Toggle overflow The server packaged inside the bootable JAR deploys the application stored in the
target/deploymentsdirectory.- Modify the code in your application code.
-
Use the
mvn package -Ddevto prompt the JBoss EAP Maven Plug-in to re-build your application and re-deploy it. Stop the server. For example:
mvn wildfly-jar:shutdown
$ mvn wildfly-jar:shutdownCopy to Clipboard Copied! Toggle word wrap Toggle overflow After you complete your application changes, package your application as a bootable JAR:
mvn package
$ mvn packageCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.17. Applying the JBoss EAP patch to your bootable JAR Copy linkLink copied to clipboard!
On a JBoss EAP bare-metal platform, you can install the patch to your bootable JAR by using a CLI script.
The CLI script issues the patch apply command to apply the patch during the bootable JAR build.
After you apply a patch to your bootable JAR, you cannot roll back from the applied patch. You must rebuild a bootable JAR without the patch.
Additionally, you can apply a legacy patch to your bootable JAR with the JBoss EAP JAR Maven plug-in. This plug-in provides a <legacy-patch-cli-script> configuration option to reference the CLI script that is used to patch the server.
The prefix legacy-* in <legacy-patch-cli-script> is related to applying archive patches to a bootable JAR. This method is similar to applying patches to regular JBoss EAP distributions.
You can use the legacy-patch-cleanup option in the JBoss EAP JAR Maven plug-in configuration to reduce the memory footprint of the bootable JAR by removing unused patch content. The option removes unused module dependencies. This option is set as false by default in the patch configuration file.
The legacy-patch-cleanup option removes the following patch content:
-
The
<JBOSS_HOME>/.installation/patchesdirectory. - Original locations of patch modules in the base layer.
- Unused modules that were added by the patch and are not referenced in the that existing module graph or patched modules graph.
-
Overlays directories that are not listed in the
.overlaysfile.
The legacy-patch-clean-up option variable is provided as a Technology Preview. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
The information outlined in this procedure also pertains to the hollow bootable JAR.
Prerequisites
- You have set up an account on the Red Hat Customer Portal.
You have downloaded the following files from the Product Downloads page:
- The JBoss EAP JBoss EAP 7.4.4 GA patch
- The JBoss EAP XP 3.0.0 patch
Procedure
Create a CLI script that defines the legacy patches you want to apply to your bootable JAR. The script must contain one or more patch apply commands. The
--override-allcommand is required when patching a server that was trimmed with Galleon layers, for example:patch apply patch-oneoff1.zip --override-all patch apply patch-oneoff2.zip --override-all patch info --json-output
patch apply patch-oneoff1.zip --override-all patch apply patch-oneoff2.zip --override-all patch info --json-outputCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Reference your CLI script in the
<legacy-patch-cli-script>element of yourpom.xmlfile. - Rebuild the bootable JAR.
Chapter 9. Reference Copy linkLink copied to clipboard!
9.1. MicroProfile Config reference Copy linkLink copied to clipboard!
9.1.1. Default MicroProfile Config attributes Copy linkLink copied to clipboard!
The MicroProfile Config specification defines three ConfigSources by default.
ConfigSources are sorted according to their ordinal number. If a configuration must be overwritten for a later deployment, the lower ordinal ConfigSource is overwritten before a higher ordinal ConfigSource.
ConfigSource | Ordinal |
|---|---|
| System properties |
|
| Environment variables |
|
|
Property files |
|
9.1.2. MicroProfile Config SmallRye ConfigSources Copy linkLink copied to clipboard!
The microprofile-config-smallrye project defines more ConfigSources you can use in addition to the default MicroProfile Config ConfigSources.
ConfigSource | Ordinal |
|---|---|
|
|
|
|
|
|
|
|
|
An explicit ordinal is not specified for these ConfigSources. They inherit the default ordinal value found in the MicroProfile Config specification.
9.2. MicroProfile Fault Tolerance reference Copy linkLink copied to clipboard!
9.2.1. MicroProfile Fault Tolerance configuration properties Copy linkLink copied to clipboard!
SmallRye Fault Tolerance specification defines the following properties in addition to the properties defined in the MicroProfile Fault Tolerance specification.
| Property | Default value | Description |
|---|---|---|
|
|
| Number of threads used by the fault tolerance mechanisms. This does not include bulkhead thread pools. |
|
|
| Size of the thread pool used for scheduling timeouts. |
9.3. MicroProfile JWT reference Copy linkLink copied to clipboard!
9.3.1. MicroProfile Config JWT standard properties Copy linkLink copied to clipboard!
The microprofile-jwt-smallrye subsystem supports the following MicroProfile Config standard properties.
| Property | Default | Description |
|---|---|---|
| mp.jwt.verify.publickey | NONE |
String representation of the public key encoded using one of the supported formats. Do not set if you have set |
| mp.jwt.verify.publickey.location | NONE |
The location of the public key, may be a relative path or URL. Do not be set if you have set |
| mp.jwt.verify.issuer | NONE |
The expected value of any |
Example microprofile-config.properties configuration:
mp.jwt.verify.publickey.location=META-INF/public.pem mp.jwt.verify.issuer=jwt-issuer
mp.jwt.verify.publickey.location=META-INF/public.pem
mp.jwt.verify.issuer=jwt-issuer
9.4. MicroProfile OpenAPI reference Copy linkLink copied to clipboard!
9.4.1. MicroProfile OpenAPI configuration properties Copy linkLink copied to clipboard!
In addition to the standard MicroProfile OpenAPI configuration properties, JBoss EAP supports the following additional MicroProfile OpenAPI properties. These properties can be applied in both the global and the application scope.
| Property | Default value | Description |
|---|---|---|
|
|
| Enables or disables registration of an OpenAPI endpoint.
When set to
You can parameterize this property to selectively enable or disable You can use this property to control which application associated with a given virtual host should generate a MicroProfile OpenAPI model. |
|
|
| You can use this property for generating OpenAPI documentation for multiple applications associated with a virtual host.
Set a distinct |
|
|
| Indicates whether auto-generated server records are absolute or relative to the location of the OpenAPI endpoint. Server records are necessary to ensure, in the presence of a non-root context path, that consumers of an OpenAPI document can construct valid URLs to REST services relative to the host of the OpenAPI endpoint.
The value
When set to |