HawtIO Diagnostic Console Guide

1. In the settings.xml file, add repository elements for the Red Hat repositories as shown in this example:

   <?xml version="1.0"?>
   <settings>
   
     <profiles>
       <profile>
         <id>extra-repos</id>
         <activation>
           <activeByDefault>true</activeByDefault>
         </activation>
         <repositories>
          <repository>
            <id>redhat-ga-repository</id>
            <url>https://maven.repository.redhat.com/ga</url>
            <releases>
              <enabled>true</enabled>
            </releases>
            <snapshots>
              <enabled>false</enabled>
            </snapshots>
           </repository>
           <repository>
             <id>redhat-ea-repository</id>
             <url>https://maven.repository.redhat.com/earlyaccess/all</url>
             <releases>
               <enabled>true</enabled>
             </releases>
             <snapshots>
               <enabled>false</enabled>
             </snapshots>
           </repository>
         </repositories>
         <pluginRepositories>
           <pluginRepository>
             <id>redhat-ga-repository</id>
             <url>https://maven.repository.redhat.com/ga</url>
             <releases>
               <enabled>true</enabled>
             </releases>
             <snapshots>
               <enabled>false</enabled>
             </snapshots>
           </pluginRepository>
           <pluginRepository>
             <id>redhat-ea-repository</id>
             <url>https://maven.repository.redhat.com/earlyaccess/all</url>
             <releases>
               <enabled>true</enabled>
             </releases>
             <snapshots>
               <enabled>false</enabled>
             </snapshots>
           </pluginRepository>
         </pluginRepositories>
       </profile>
     </profiles>
   
     <activeProfiles>
       <activeProfile>extra-repos</activeProfile>
     </activeProfiles>
   
   </settings>

Procedure:

1. Install the latest version of HawtIO on your machine using the jbang command:

   $ jbang app install -Dhawtio.jbang.version=4.1.0.redhat-00015 hawtio@hawtio/hawtio

   Note

   This installation method is available only with jbang>=0.115.0.

2. It will install the HawtIO command. Launch an HawtIO instance with the following command:

   $ hawtio

3. The command will automatically open the console at http://localhost:8080/hawtio/. To change the port number, run the following command:

   $ hawtio --port 8090

4. For more information on the configuration options of the CLI, run the following code:

   $ hawtio --help
   Usage: hawtio [-hjoV] [-c=<contextPath>] [-d=<plugins>] [-e=<extraClassPath>]
                 [-H=<host>] [-k=<keyStore>] [-l=<warLocation>] [-p=<port>]
                 [-s=<keyStorePass>] [-w=<war>]
   Run HawtIO
     -c, --context-path=<contextPath>
                         Context path.
     -d, --plugins-dir=<plugins>
                         Directory to search for .war files to install as 3rd
                           party plugins.
     -e, --extra-class-path=<extraClassPath>
                         Extra class path.
     -h, --help          Print usage help and exit.
     -H, --host=<host>   Hostname to listen to.
     -j, --join          Join server thread.
     -k, --key-store=<keyStore>
                         JKS keyStore with the keys for https.
     -l, --war-location=<warLocation>
                         Directory to search for .war files.
     -o, --open-url      Open the web console automatic in the web browser.
     -p, --port=<port>   Port number.
     -s, --key-store-pass=<keyStorePass>
                         Password for the JKS keyStore with the keys for https.
     -V, --version       Print HawtIO version
     -w, --war=<war>     War file or directory of the hawtio web application.

1. Add io.hawt:hawtio-quarkus and the supporting Camel Quarkus extensions to the dependencies in pom.xml:

   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>io.hawt</groupId>
         <artifactId>hawtio-bom</artifactId>
         <version>4.1.0.redhat-00015</version>
         <type>pom</type>
         <scope>import</scope>
       </dependency>
     </dependencies>
     <!-- ... other BOMs or dependencies ... -->
   </dependencyManagement>
   
   <dependencies>
     <dependency>
       <groupId>io.hawt</groupId>
       <artifactId>hawtio-quarkus</artifactId>
     </dependency>
   
      <!-- Mandatory for enabling Camel management via JMX / HawtIO -->
     <dependency>
       <groupId>org.apache.camel.quarkus</groupId>
       <artifactId>camel-quarkus-management</artifactId>
     </dependency>
   
     <!-- (Optional) Required for HawtIO Camel route diagram tab -->
     <dependency>
       <groupId>org.apache.camel.quarkus</groupId>
       <artifactId>camel-quarkus-jaxb</artifactId>
     </dependency>
   
     <!-- ... other dependencies ... -->
   </dependencies>

2. Disable the authentication by adding the following configuration to application.properties:

   quarkus.hawtio.authenticationEnabled = false

   1. You can also configure authentication. Refer "Quarkus authentication mechanisms".

3. Run HawtIO with your Quarkus application in development mode as follows:

   mvn compile quarkus:dev

4. Open http://localhost:8080/hawtio/ to view the HawtIO console.

Procedure:

1. Add io.hawt:hawtio-springboot and the supporting Camel Spring Boot starters to the dependencies in pom.xml:

   <dependencyManagement>
     <dependencies>
       <dependency>
         <groupId>io.hawt</groupId>
         <artifactId>hawtio-bom</artifactId>
         <version>4.1.0.redhat-00015</version>
         <type>pom</type>
         <scope>import</scope>
       </dependency>
       <!-- ... other BOMs or dependencies ... -->
     </dependencies>
   </dependencyManagement>
   
   <dependencies>
     <dependency>
       <groupId>io.hawt</groupId>
       <artifactId>hawtio-springboot</artifactId>
     </dependency>
   
      <!-- Mandatory for enabling Camel management via JMX / HawtIO -->
     <dependency>
       <groupId>org.apache.camel.springboot</groupId>
       <artifactId>camel-management-starter</artifactId>
     </dependency>
   
     <!-- (Optional) Required for HawtIO Camel route diagram tab -->
     <dependency>
       <groupId>org.apache.camel.springboot</groupId>
       <artifactId>camel-spring-boot-xml-starter</artifactId>
     </dependency>
   
     <!-- ... other dependencies ... -->
   </dependencies>

2. Enable the HawtIO and Jolokia endpoints by adding the following lines to application.properties:

   spring.jmx.enabled = true
   management.endpoints.web.exposure.include = hawtio,jolokia

3. Run HawtIO with your Spring Boot application in development mode as follows:

   mvn spring-boot:run

4. Open http://localhost:8080/actuator/hawtio to view the HawtIO console.

1. Prepare Keycloak server
2. Deploy HawtIO to your favourite runtime (Quarkus, Spring Boot, WildFly, Karaf, Jetty, Tomcat, etc.) and configure it to use Keycloak for authentication

1. Log in to the OpenShift console in the web browser as a user with cluster admin access.
2. Click Operators and then click OperatorHub.
3. In the search field window, type HawtIO to filter the list of operators. Click HawtIO Operator.

4. In the HawtIO Operator install window, click Install. The Create Operator Subscription form opens:

   1. For Update Channel, select stable-v1.

   2. For Installation Mode, accept the default (a specific namespace on the cluster).

      Note

      This mode determines what namespaces the operator will monitor for HawtIO CRs. This is different to what namespaces HawtIO will monitor when it is fully deployed. The latter can be configured via the HawtIO CR.

   3. For Installed Namespace, select the namespace in which you want to install HawtIO Operator.

   4. For the Update Approval, select Automatic or Manual to configure how OpenShift handles updates to HawtIO Operator.

      1. If the Automatic updates option is selected and a new version of HawtIO Operator is available, the OpenShift Operator Lifecycle Manager (OLM) automatically upgrades the running instance of HawtIO without human intervention;
      2. If the Manual updates option is selected and a newer version of an Operator is available, the OLM only creates an update request. A Cluster Administrator must then manually approve the update request to have HawtIO Operator updated to the new version.
5. Click Install and OpenShift installs HawtIO Operator into the current namespace.
6. To verify the installation, click Operators and then click Installed Operators. HawtIO should be visible in the list of operators.

7. To deploy HawtIO by using the OpenShift web console:

   1. In the list of Installed Operators, under the Name column, click HawtIO Operator.
   2. On the Operator Details page under Provided APIs, click Create HawtIO.

   3. Accept the configuration default values or optionally edit them.

      1. For Replicas, to increase HawtIO performance (for example, in a high availability environment), the number of pods allocated to HawtIO can be increased;
      2. For RBAC (role-based access control), only specify a value in the Config Map field if you want to customize the default RBAC behaviour and if the ConfigMap file already exists in the namespace in which you installed HawtIO Operator
      3. For Nginx, see Performance tuning for HawtIO Operator installation

      4. For Type, specify either:

         1. Cluster: for HawtIO to monitor all namespaces on the OpenShift cluster for any HawtIO-enabled applications;
         2. Namespace: for HawtIO to monitor only the HawtIO-enabled applications that have been deployed in the same namespace.
   4. Click Create. The HawtIO Operator Details page opens and shows the status of the deployment.

8. To open HawtIO:

   1. For a namespace deployment: In the OpenShift web console, open the project in which the HawtIO operator is installed, and then select Overview. In the Project Overview page, scroll down to the Launcher section and click the HawtIO link.
   2. For a cluster deployment, in the OpenShift web console’s title bar, click the grid icon. In the popup menu, under Red Hat Applications, click the HawtIO URL link.
   3. Log into HawtIO. An Authorize Access page opens in the browser listing the required permissions.
   4. Click Allow selected permissions. HawtIO opens in the browser and shows any HawtIO-enabled application pods that are authorized for access.
9. Click Connect to view the monitored application. A new browser window opens showing the application in HawtIO.

1. admin: if a user can update a pod in OpenShift, then the user is conferred the admin role for HawtIO. The user can perform write MBean operations in HawtIO for the pod.
2. viewer: if a user can get a pod in OpenShift, then the user is conferred the viewer role for HawtIO. The user can perform read-only MBean operations in HawtIO for the pod.

1. auth: The authentication configuration | type: object

   1. clientCertCheckSchedule: CronJob schedule that defines how often the expiry of the certificate will be checked. Client rotation isn’t enabled if the schedule isn’t set | type: string
   2. clientCertCommonName: The generated client certificate CN | type: string
   3. clientCertExpirationDate: The generated client certificate expiration date | type: string | format: date-time
   4. clientCertExpirationPeriod: The duration in hours before the expiration date, during which the certification can be rotated. The default is set to 24 hours | type: integer

2. config: The HawtIO console configuration | type: object

   1. about: The information to be displayed in the About page | type: object

      1. additionalInfo: The text for the description section | type: string
      2. copyright: The text for the copyright section | type: string
      3. imgSrc: The image displayed in the page. It can be a path, relative to the HawtIO status URL, or an absolute URL | type: string

      4. productInfo: List of product information | type: array

         1. items: The product information displayed in the About page | type: object | required: [ "name", "value" ]

            1. name: The name of the product information | type: string
            2. value: The value of the product information | type: string
      5. title: The title of the page | type: string

   2. branding: The UI branding | type: object

      1. appLogoUrl: The URL of the logo, that displays in the navigation bar. It can be a path, relative to the HawtIO status URL, or an absolute URL. | type: string
      2. appName: The application title, that usually displays in the Web browser tab. | type: string
      3. css: The URL of an external CSS stylesheet, that can be used to style the application. It can be a path, relative to the HawtIO status URL, or an absolute URL. | type: string
      4. favicon: The URL of the favicon, that usually displays in the Web browser tab. It can be a path, relative to the HawtIO status URL, or an absolute URL. | type: string

   3. disabledRoutes: Disables UI components with matching routes | type: array |

      1. items: type: string

   4. online: The OpenShift related configuration | type: object

      1. consoleLink: The configuration for the OpenShift Web console link. A link is added to the application menu when the HawtIO deployment is equal to 'cluster'. Otherwise, a link is added to the HawtIO project dashboard. | type: object

         1. imageRelativePath: The path, relative to the HawtIO status URL, for the icon used in front of the link in the application menu. It is only applicable when the HawtIO deployment type is equal to cluster. The image should be square and will be shown at 24x24 pixels. | type: string
         2. section: The section of the application menu in which the link should appear. It is only applicable when the HawtIO deployment type is equal to 'cluster'. | type: string
         3. text: The text display for the link | type: string
      2. projectSelector: The selector used to watch for projects. It is only applicable when the HawtIO deployment type is equal to 'cluster'. By default, all the projects the logged in user has access to are watched. The string representation of the selector must be provided, as mandated by the --selector, or -l, options from the kubectl get command. See: Kubernetes Labels and Selectors | type: string

3. externalRoutes: List of external route names that will be annotated by the operator to access the console using the routes | type: array |

   1. items: type: string

4. metadataPropagation: The configuration for which metadata on HawtIO custom resources to propagate to generated resources such as deployments, pods, services, and routes | type: object

   1. annotations: Annotations to propagate | type: array |

      1. items: type: string

   2. labels: Labels to propagate | type: array |

      1. items: type: string

5. nginx: The Nginx runtime configuration type: object

   1. clientBodyBufferSize: The buffer size for reading client request body. Defaults to 256k. | type: string
   2. proxyBuffers: The number and size of the buffers used for reading a response from the proxied server, for a single connection. Defaults to 16 128k. | type: string
   3. subrequestOutputBufferSize: The size of the buffer used for storing the response body of a subrequest. Defaults to 10m. | type: string

6. rbac: The RBAC configuration | type: object

   1. configMap: The name of the ConfigMap that contains the ACL definition. | type: string
   2. disableRBACRegistry: Disable performance improvement brought by RBACRegistry and revert to the classic behavior. Defaults to false. | type: boolean
7. replicas: Number of desired pods. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1. | type: integer | format: int32

8. resources: The HawtIO console compute resources | type: object

   1. claims: Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. This is an alpha field and requires enabling the DynamicResourceAllocation feature gate. This field is immutable. It can only be set for containers. | type: array |

      1. items: ResourceClaim references one entry in PodSpec.ResourceClaims. | type: object | required: [ "name" ]
      2. name: Name must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container. | type: string
   2. limits: Limits describes the maximum amount of compute resources allowed. See: Kubernetes Resource Management for Pods and Containers | type: object
   3. requests: Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. See: Kubernetes Resource Management for Pods and Containers | type: object

9. route: Custom certificate configuration for the route (not necessary on most OpenShift installations). | type: object

   1. caCert: Ca certificate secret key selector | type: object | required: [ "key" ]

      1. key: The key of the secret to select from. Must be a valid secret key. | type: string
      2. name: Name of the referent. See: Kubernetes Names | type: string
      3. optional: Specify whether the Secret or its key must be defined | type: boolean

   2. certSecret: Name of the TLS secret with the custom certificate used for the route TLS termination | type: object

      1. name: Name of the referent. See: Kubernetes Names | type: string
10. routeHostName: The edge host name of the route that exposes the HawtIO service externally. If not specified, it is automatically generated and is of the form: [-]. where is the default routing sub-domain as configured for the cluster. Note that the operator will recreate the route if the field is emptied, so that the host is re-generated. | type: string

11. type: The deployment type. Defaults to cluster. | type: string

    1. cluster: HawtIO is capable of discovering and managing applications across all namespaces the authenticated user has access to.
    2. namespace: HawtIO is capable of discovering and managing applications within the deployment namespace.
12. version: The HawtIO console container image version. Deprecated: Remains for legacy purposes in respect of older operators (<1.0.0) still requiring it for their installs. | type: string

1. Customize these values as needed:

   archetypeVersion

   4.8.0.redhat-00022

   groupId

   io.hawtio.online.examples

   artifactId

   hawtio-online-example-camel-springboot-os

   version

   1.0.0

2. Run the maven archetype:

   mvn archetype:generate  \
     -DarchetypeGroupId=org.apache.camel.archetypes  \
     -DarchetypeArtifactId=camel-archetype-spring-boot  \
     -DarchetypeVersion=4.8.0.redhat-00022  \
     -DgroupId=io.hawt.online.examples  \
     -DartifactId=hawtio-online-example  \
     -Dversion=1.0.0  \
     -DinteractiveMode=false \
     -Dpackage=io.hawtio

3. Change into the new project named artifactId (in the above example: hawtio-online-example)

   An example hello world application is created, and you can compile it.

   At this point, the application should be executable locally.

4. Use the mvn spring-boot:run maven goal to test the application:

   $ mvn spring-boot:run

1. Add the needed dependencies to the <dependencies> section:

   <dependencies>
     ...
   
     <!-- Camel -->
     ...
   
     <!-- Dependency is mandatory for exposing Jolokia endpoint -->
     <dependency>
         <groupId>org.apache.camel.springboot</groupId>
         <artifactId>camel-jolokia-starter</artifactId>
     </dependency>
   
     <!-- Optional: enables debugging support for Camel -->
     <dependency>
       <groupId>org.apache.camel</groupId>
       <artifactId>camel-debug</artifactId>
       <version>4.8.0</version>
    </dependency>
   
   ...
   </dependencies>

   For configuration details, see the Jolokia component documentation

2. To enable inflight monitoring also add the following property to the application.properties file according to the Spring Boot documentation:

   camel.springboot.inflight-repository-browse-enabled=true

1. Prerequisites

   • The appropriate project selected (see Documentation);
   • All files have been configured.

2. Run the following maven command:

   mvn clean install -DskipTests -P openshift

   The application is compiled with S2I and deployed to OpenShift.

3. Verify that the Spring Boot application is running correctly:

   Follow the Verification steps detailed in the Deploying Red Hat build of Quarkus Java applications to OpenShift Container Platform section of the Red Hat build of Quarkus documentation.

4. When your new Spring Boot application is running correctly, it is discovered by the HawtIO instance (depending on its mode - 'Namespace' mode requires it to be in the same project).

   The new container should be displayed like in the following screenshot:

   

5. Click Connect to examine the Spring Boot application can be with HawtIO:

   

1. For a new Quarkus application, the maven quarkus quick-start is available, eg.

   mvn io.quarkus.platform:quarkus-maven-plugin:3.14.2:create \
   -DprojectGroupId=org.hawtio \
   -DprojectArtifactId=quarkus-helloworld \
   -Dextensions='openshift,camel-quarkus-quartz'

   1. Use the quarkus-maven-plugin to generate the project scaffolding
   2. Set the project maven groupId to org.hawtio and customize as appropriate
   3. Set the project maven artifactId to quarkus-helloworld and customize as appropriate

   4. Use the following Quarkus extensions:

      1. openshift: Enables maven to deploy to local OpenShift cluster;
      2. camel-quarkus-quartz: Enables the Camel extension quartz for use in the example Quarkus application
   5. Execute the quick-start to create the scaffolding for the Quarkus project and then allow further customization for individual applications.

2. To build and deploy the application to OpenShift, the following properties should be specified in the file src/main/resources/application.properties (see related documentation).

     # Set the Docker build strategy
     quarkus.openshift.build-strategy=docker
   
     # Expose the service to create an OpenShift Container Platform route
     quarkus.openshift.route.expose=true

1. For this example, a simple Camel ‘hello-world’ Quarkus application is to be implemented. Add the file src/main/java/org/hawtio/SampleCamelRoute.java to the project with the following content:

   package org.hawtio;
   
   import jakarta.enterprise.context.ApplicationScoped;
   import org.apache.camel.builder.endpoint.EndpointRouteBuilder;
   
   @ApplicationScoped
   public class SampleCamelRoute extends EndpointRouteBuilder
   {
   
   	@Override
   	public void configure()
   	{
   		from(quartz("cron").cron("{{quartz.cron}}")).routeId("cron")
   			.setBody().constant("Hello Camel! - cron")
   			.to(stream("out"))
   			.to(mock("result"));
   
        	from("quartz:simple?trigger.repeatInterval={{quartz.repeatInterval}}").routeId("simple")
   			.setBody().constant("Hello Camel! - simple")
   			.to(stream("out"))
   			.to(mock("result"));
   	}
   }

   1. This example logs "Hello Camel …​" entries in the container log via a Camel route.

2. Modify the src/main/resources/application.properties file with the following properties:

     # Camel
     camel.context.name = SampleCamel
   
     # Uncomment the following to enable the Camel plugin Trace tab
     #camel.main.tracing = true
     #camel.main.backlogTracing = true
     #camel.main.useBreadcrumb = true
   
     # Uncomment to enable debugging of the application and in turn
     # enables the Camel plugin Debug tab even in non-development
     # environment
     #quarkus.camel.debug.enabled = true
   
     # Define properties for the Camel quartz component used in the
     # example
     quartz.cron = 0/10 * * * * ?
     quartz.repeatInterval = 10000

3. Add the following dependencies to the <dependencies> section of file pom.xml. These are required due to the route defined in src/main/java/org/hawtio/SampleCamelRoute.java; these will need to be modified if the Camel route added to the application is changed:

   <dependency>
     <groupId>org.apache.camel.quarkus</groupId>
     <artifactId>camel-quarkus-stream</artifactId>
   </dependency>
   <dependency>
     <groupId>org.apache.camel.quarkus</groupId>
     <artifactId>camel-quarkus-mock</artifactId>
   </dependency>

1. In order to ensure that maven properties can be passed through to the src/main/resources/application.properties file, the following should be added to the <build> section of the file pom.xml:

   <resources>
     <resource>
       <directory>src/main/resources</directory>
       <filtering>true</filtering>
     </resource>
   </resources>

2. Add the following Jolokia properties to the <properties> section of the file pom.xml. These will be used to configure the running jolokia java-agent in the Quarkus container (for an explanation of the properties, please refer to the Jolokia JVM Agent documentation):

     <properties>
     	...
   
     	<!-- The current HawtIO Jolokia Version -->
     	<jolokia-version>2.1.0</jolokia-version>
   
     	<!--
   
       ===============================================================
       === Jolokia agent configuration for the connection with HawtIO
       ===============================================================
   
   	It should use HTTPS and SSL client authentication at minimum.
   	The client principal should match those the HawtIO instance provides (the default is `hawtio-online.hawtio.svc`).
     	-->
     	<jolokia.protocol>https</jolokia.protocol>
     	<jolokia.host>*</jolokia.host>
     	<jolokia.port>8778</jolokia.port>
   	<jolokia.useSslClientAuthentication>true</jolokia.useSslClientAuthentication>
   	<jolokia.caCert>/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt</jolokia.caCert>
     	<jolokia.clientPrincipal.1>cn=hawtio-online.hawtio.svc</jolokia.clientPrincipal.1>
     	<jolokia.extendedClientCheck>true</jolokia.extendedClientCheck>
     	<jolokia.discoveryEnabled>false</jolokia.discoveryEnabled>
   
   	...
     </properties>

3. Add the following dependencies to the <dependencies> section of the file pom.xml:

   <!--
   	This dependency is required for enabling Camel management via JMX / HawtIO.
   -->
   <dependency>
   	<groupId>org.apache.camel.quarkus</groupId>
   	<artifactId>camel-quarkus-management</artifactId>
   </dependency>
   
   <!--
   	This dependency is optional for monitoring with HawtIO but is required for HawtIO view the Camel routes source XML.
   -->
   <dependency>
   	<groupId>org.apache.camel.quarkus</groupId>
   	<artifactId>camel-quarkus-jaxb</artifactId>
   </dependency>
   
   <!--
   	Add this optional dependency, to enable Camel plugin debugging feature.
   -->
   <dependency>
   	<groupId>org.apache.camel.quarkus</groupId>
   	<artifactId>camel-quarkus-debug</artifactId>
   </dependency>
   
   <!--
   	This dependency is required to include the Jolokia agent jvm for
   	access to JMX beans.
   -->
   <dependency>
   	<groupId>org.jolokia</groupId>
   	<artifactId>jolokia-agent-jvm</artifactId>
   	<version>${jolokia-version}</version>
   	<classifier>javaagent</classifier>
   </dependency>

4. With maven property filtering implemented, the ${jolokia…​} environment variables should be passed-through from the pom.xml during the building of the application. The purpose of this property is to append a JVM option to the executing process of the container that runs the jolokia java-agent. Modify the src/main/resources/application.properties file with the following property:

   # Enable the jolokia java-agent on the quarkus application
   quarkus.openshift.env.vars.JAVA_OPTS_APPEND=-javaagent:lib/main/org.jolokia.jolokia-agent-jvm-${jolokia-version}-javaagent.jar=protocol=${jolokia.protocol}\,host=${jolokia.host}\,port=${jolokia.port}\,useSslClientAuthentication=${jolokia.useSslClientAuthentication}\,caCert=${jolokia.caCert}\,clientPrincipal.1=${jolokia.clientPrincipal.1}\,extendedClientCheck=${jolokia.extendedClientCheck}\,discoveryEnabled=${jolokia.discoveryEnabled}

1. For HawtIO to discover the deployed application, a port named jolokia must be present on the executing container. Therefore, it is necessary to add the following properties in the src/main/resources/application.properties file:

   # Define the Jolokia port on the container for HawtIO access
   quarkus.openshift.ports.jolokia.container-port=${jolokia.port}
   quarkus.openshift.ports.jolokia.protocol=TCP

1. Command-line (CLI) is already logged-in to the OpenShift cluster and the project is selected.

2. When all files have been configured, the following maven command can be executed:

   ./mvnw clean package -Dquarkus.kubernetes.deploy=true

3. Verify that the Quarkus application is running correctly using the Verification steps detailed here.

4. Assuming the application is running correctly, the new Quarkus application should be discovered by an HawtIO instance (depending on its mode - 'Namespace' mode requires it to be in the same project). The new container should be displayed like in the following screenshot:

   

5. By clicking Connect, the Quarkus application can be examined by HawtIO.

   

1. Deploying Quarkus application to OpenShift
2. A Quarkus application: Getting started
3. Using the Quarkus Openshift Extension

1. In the Camel tab’s tree view, click Camel Contexts.
2. Check the box next to one or more contexts in the list.
3. Click Start or Suspend.

4. To delete a context:

   1. Stop the context.
   2. Click the ellipse icon and then select Delete from the dropdown menu.

1. In the Camel tab’s tree view, click a Camel application.
2. To view a list of application attributes and values, click Attributes.
3. To view a graphical representation of the application attributes, click Chart and then click Edit to select the attributes that you want to see in the chart.
4. To view inflight and blocked exchanges, click Exchanges.
5. To view application endpoints, click Endpoints. You can filter the list by URL, Route ID, and direction.
6. To view, enable, and disable statistics related to the Camel built-in type conversion mechanism that is used to convert message bodies and message headers to different types, click Type Converters.
7. To view and execute JMX operations, such as adding or updating routes from XML or finding all Camel components available in the classpath, click Operations.

1. To view a list of routes:

   1. Click the Camel tab.

   2. In the tree view, click the application’s routes folder:

      

2. To start, stop, or delete one or more routes:

   1. Check the box next to one or more routes in the list.
   2. Click Start or Stop.

   3. To delete a route, you must first stop it. Then click the ellipse icon and select Delete from the dropdown menu.

      
      Note
      • When you delete a route, you remove it from the deployed application.
      • You can also select a specific route in the tree view and then click the upper-right menu to start, stop, or delete it.
3. To view a graphical diagram of the routes, click Route Diagram.
4. To view inflight and blocked exchanges, click Exchanges.
5. To view endpoints, click Endpoints. You can filter the list by URL, Route ID, and direction.
6. Click Type Converters to view, enable, and disable statistics related to the Camel built-in type conversion mechanism, which is used to convert message bodies and message headers to different types.

7. To interact with a specific route:

   1. In the Camel tab’s tree view, select a route. To view a list of route attributes and values, click Attributes.
   2. To view a graphical representation of the route attributes, click Chart. You can click Edit to select the attributes that you want to see in the chart.
   3. To view inflight and blocked exchanges, click Exchanges.
   4. Click Operations to view and execute JMX operations on the route, such as dumping the route as XML or getting the route’s Camel ID value.

8. To trace messages through a route:

   1. In the Camel tab’s tree view, select a route.
   2. Select Trace, and then click Start tracing.

9. To send messages to a route:

   1. In the Camel tab’s tree view, open the context’s endpoints folder and then select an endpoint.
   2. Click the Send subtab.
   3. Configure the message in JSON or XML format.
   4. Click Send.
   5. Return to the route’s Trace tab to view the flow of messages through the route.

1. In the Camel tab’s tree view, select a route.
2. Select Debug, and then click Start debugging.

3. To add a breakpoint, select a node in the diagram and then click Add breakpoint. A red dot appears in the node:

   

4. The node is added to the list of breakpoints:

   

5. Click the down arrow to step to the next node or the Resume button to resume running the route.

   
6. Click the Pause button to suspend all threads for the route.
7. Click Stop debugging when you are done. All breakpoints are cleared.

1. Resource Server:

   The server component hosting protected resource(s), where access is restricted or granted based on access tokens. Usually this server is accessed through REST API and doesn’t provide user interface on its own.

2. Client:

   The application (typically with user interface) that accesses resource server on behalf of a user (which is treated as resource owner). In order to access resource server it is mandatory for the client to obtain an access token first.

   In OpenID Connect specification, the client is named relying party (RP).

3. Authorization Server:

   The server that coordinates communication between a client and resource server. The client asks authorization server to authenticate the user (resource owner) and if the authentication succeeds, an access token is issued for the client to access resource server.

   In OpenID Connect specification, the authorization server is named OpenID Provider (OP).

1. admin/admin with roles manager, admin, viewer and user
2. viewer/viewer with roles viewer and user
3. jdoe/jdoe with just user role

1. Web platform:

   This kind of client is suitable for server-side applications and APIs.

2. SPA platform:

   SPA applications are running within a browser where it’s natural to use "Authorization Code Flow" and so-called public client. The reason is that there’s no good way of storing credentials and secrets in browser application.