Chapter 3. Administer MicroProfile in JBoss EAP

Procedure

1. Open your terminal.

2. Run the following command:

   $ <JBOSS_HOME>/bin/jboss-cli.sh -c <<EOF
       if (outcome != success) of /subsystem=opentelemetry:read-resource
           /extension=org.wildfly.extension.opentelemetry:add()
           /subsystem=opentelemetry:add()
       end-if
       /extension=org.wildfly.extension.microprofile.telemetry:add
       /subsystem=microprofile-telemetry:add
       reload
   EOF

Procedure

1. Open your microprofile-config.properties file.

2. Set the otel.sdk.disabled property to false:

   otel.sdk.disabled=false

Procedure

1. Create a directory where you want to store the files:

   $ mkdir -p ~/config/prop-files/

2. Navigate to the directory:

   $ cd ~/config/prop-files/

3. Create a file name to store the value for the property name:

   $ touch name

4. Add the value of the property to the file:

   $ echo "jim" > name

5. 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})

   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>

Procedure

1. Open your terminal.

2. Create a directory where you want to store your files:

   mkdir -p ~/etc/config/prop-files/

3. Navigate to the directory that you created:

   cd ~/etc/config/prop-files/

4. Create a file name to store the value for the property name:

   touch name

5. Add the value of the property to the file:

   echo "jim" > name

6. Run the following command in the CLI to create a ConfigSource in which the filename is the property and the file contains the value of the property:

   /subsystem=microprofile-config-smallrye/config-source=prop-files:add(dir={path=/etc/config, root=true})

7. This results in the XML configuration:

   <subsystem
   xmlns="urn:wildfly:microprofile-config-smallrye:2.0">
    <config-source name="prop-files">
      <dir path="/etc/config" root="true"/>
    </config-source>
   </subsystem>

Procedure

1. Add the MicroProfile Fault Tolerance extension using the following management CLI command:

   /extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add

2. Enable the microprofile-fault-tolerance-smallrye subsystem using the following managenent command:

   /subsystem=microprofile-fault-tolerance-smallrye:add

3. Reload the server with the following management command:

   reload

Procedure

1. Navigate to the Runtime tab and select the server.
2. In the Monitor column, click MicroProfile Health View.

Procedure

1. Set the security-enabled attribute to true on the microprofile-health-smallrye subsystem.

   /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)

2. Reload the server for the changes to take effect.

   reload

   Any subsequent attempt to access the /health endpoint triggers an authentication prompt.

Procedure

1. Enable the MicroProfile JWT smallrye extension in JBoss EAP:

   /extension=org.wildfly.extension.microprofile.jwt-smallrye:add

2. Enable the microprofile-jwt-smallrye subsystem:

   /subsystem=microprofile-jwt-smallrye:add

3. Reload the server:

   reload

   The microprofile-jwt-smallrye subsystem is enabled.

Procedure

1. Enable the MicroProfile OpenAPI smallrye extension in JBoss EAP:

   /extension=org.wildfly.extension.microprofile.openapi-smallrye:add()

2. Enable the microprofile-openapi-smallrye subsystem using the following management command:

   /subsystem=microprofile-openapi-smallrye:add()

3. Reload the server.

   reload

   The microprofile-openapi-smallrye subsystem is enabled.

Procedure

1. Create a directory in the application source tree:

   $ mkdir APPLICATION_ROOT/src/main/webapp/META-INF

   APPLICATION_ROOT is the directory containing the pom.xml configuration file for the application.

2. Query the OpenAPI endpoint, redirecting the output to a file:

   $ curl http://localhost:8080/openapi?format=JSON > src/main/webapp/META-INF/openapi.json

   By default, the endpoint serves a YAML document, format=JSON specifies that a JSON document is returned.

3. 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

4. Rebuild the application:

   $ mvn clean install

5. Deploy the application again using the following management CLI commands:

   1. Undeploy the application:

      undeploy microprofile-openapi.war

   2. Deploy the application:

      deploy APPLICATION_ROOT/target/microprofile-openapi.war

      JBoss EAP now serves a static OpenAPI document at the OpenAPI endpoint.

Procedure

1. Open the JBoss EAP management CLI.

2. Enter the following code:

   [standalone@localhost:9990 /] /extension=org.wildfly.extension.microprofile.reactive-messaging-smallrye:add
   {"outcome" => "success"}
   
   [standalone@localhost:9990 /] /subsystem=microprofile-reactive-messaging-smallrye:add
   {
       "outcome" => "success",
       "response-headers" => {
           "operation-requires-reload" => true,
           "process-state" => "reload-required"
       }
   }

   Note

   If you provision a server using Galleon, either on OpenShift or not, make sure you include the microprofile-reactive-messaging Galleon layer to get the core MicroProfile 2.0.1 and reactive messaging functionality, and to enable the required subsystems and extensions. Note that this configuration does not contain the JBoss EAP modules you need to enable connectors. Use the microprofile-reactive-messaging-kafka layer or the microprofile-reactive-messaging-amqp layer to enable the Kafka connector or the AMQP connector, respectively.

Procedure

1. Run the following CLI script to update the default standalone.xml server configuration file:

   $ <EAP_HOME>/bin/jboss-cli.sh --file=docs/examples/enable-microprofile.cli

2. Select a standalone server configuration other than the default standalone.xml server 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>

3. The specified configuration file now includes MicroProfile subsystems and extensions.

Procedure

1. Add shared and override properties at the subsystem level by using the following commands:

   /subsystem=microprofile-config-smallrye/config-source=subsystem-config:add(properties={"shared.property" => "subsystem-level"})
   /subsystem=microprofile-config-smallrye/config-source=subsystem-config:add(properties={"override.property" => "subsystem-value"})

   • shared.property: Available to all deployments unless a deployment overrides it.
   • override.property: Set at subsystem level but will be overridden in app1.war to demonstrate deployment-level priority.

2. Create a microprofile-config.properties file in the META-INF directory of each application with the following properties:

   For app1.war:

   app.property=app1-level
   override.property=deployment-value
   custom.property=app1-only

   This configuration includes:

   • app.property: A deployment-specific value.
   • override.property: Overrides a subsystem-level property.

   • custom.property: Unique to this deployment.

     For app2.war:

     app.property=app2-level

     This configuration includes only app.property, which defines a deployment-specific value.

3. Deploy the first application, app1.war, by using the following command:

   ./jboss-cli.sh --connect --command="deploy /path/to/app1.war"

4. Deploy the second application, app2.war, by using the following command:

   ./jboss-cli.sh --connect --command="deploy /path/to/app2.war"

Verification

1. Verify that the shared subsystem property is available to both deployments by using the following commands:

   curl -X GET http://localhost:8080/app1/config/shared.property
   # Expected output: subsystem-level
   
   curl -X GET http://localhost:8080/app2/config/shared.property
   # Expected output: subsystem-level

2. Verify that each deployment has its own deployment-specific property by using the following commands:

   curl -X GET http://localhost:8080/app1/config/app.property
   # Expected output: app1-level
   
   curl -X GET http://localhost:8080/app2/config/app.property
   # Expected output: app2-level

3. Verify that the deployment-level property overrides the subsystem-level property in app1.war by using the following commands:

   curl -X GET http://localhost:8080/app1/config/override.property
   # Expected output: deployment-value
   
   curl -X GET http://localhost:8080/app2/config/override.property
   # Expected output: subsystem-value

4. Verify that custom.property exists only in app1.war by using the following commands:

   curl -X GET http://localhost:8080/app1/config/custom.property
   # Expected output: app1-only
   
   curl -X GET http://localhost:8080/app2/config/custom.property
   # Expected output: 404 Not Found