Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 2. What is new in JWS Operator 2.x?

JWS Operator 2.x provides level-2 Operator capabilities such as seamless integration. JWS Operator 2.x also supports Red Hat JBoss Web Server metering labels and includes some new or enhanced Custom Resource Definition (CRD) parameters.

2.1. What is new in the JWS Operator 2.1 release?

The JWS Operator 2.1 release includes the following new features and enhancements.

New webhookSecrets parameter

JWS Operator 2.1 introduces a webhookSecrets parameter under the webImageStream:webSources hierarchy in the CRD. This parameter specifies secret names for triggering a build through a generic, GitHub, or GitLab webhook.

The webhookSecrets parameter contains generic, github, and gitlab fields.

For more information, see JWS Operator CRD parameters.

New tlsConfig parameter

JWS Operator 2.1 introduces a tlsConfig parameter in the CRD. This parameter specifies the TLS configuration for a web server.

The tlsConfig parameter contains routeHostname, certificateVerification, tlsSecret, and tlsPassword fields.

For more information, see JWS Operator CRD parameters.

New environmentVariables parameter

JWS Operator 2.1 introduces an environmentVariables parameter in the CRD. This parameter specifies the environment variables for the deployment.

For more information, see JWS Operator CRD parameters.

New persistentLogs parameter

JWS Operator 2.1 introduces a persistentLogs parameter in the CRD. This parameter specifies persistent volume and logging configuration.

The persistentLogs parameter contains catalinaLogs, enableAccessLogs, volumeName, and storageClass fields.

For more information, see JWS Operator CRD parameters.

New podResources parameter

JWS Operator 2.1 introduces a podResources parameter in the CRD. This parameter specifies the configuration of the central processing unit (CPU) and memory resources that the web server uses.

For more information, see JWS Operator CRD parameters.

New securityContext parameter

JWS Operator 2.1 introduces a securityContext parameter in the CRD. This parameter defines the security capabilities that are required to run the application.

For more information, see JWS Operator CRD parameters.

New useInsightsClient parameter

JWS Operator 2.1 introduces a useInsightsClient parameter in the CRD. This parameter indicates whether to create a connection with the runtimes inventory operator that Red Hat provides.

You can enable debug logging for the Insights client by setting the INSIGHTS_DEBUG environment variable to true.

Note

The useInsightsClient parameter requires use of a Red Hat JBoss Web Server 6.1 or later image.

This parameter is available as a Technology Preview only.

For more information, see JWS Operator CRD parameters.

Deprecated genericWebhookSecret parameter

JWS Operator 2.1 deprecates the genericWebhookSecret parameter that is under the webImageStream.webSources.webSourcesParams hierarchy in the CRD.

This parameter is superseded by the webImageStream.webSources.webhookSecrets.generic parameter.

For more information, see JWS Operator CRD parameters.

Deprecated githubWebhookSecret parameter

JWS Operator 2.1 deprecates the githubWebhookSecret parameter that is under the webImageStream.webSources.webSourcesParams hierarchy in the CRD.

This parameter is superseded by the webImageStream.webSources.webhookSecrets.github parameter.

For more information, see JWS Operator CRD parameters.

Enhanced format for default generated hostnames

JWS Operator 2.1 uses an enhanced format for default generated hostnames that can consist of an application name and a project name that are each up to 63 characters in length.

2.2. What is new in the JWS Operator 2.0 release?

The JWS Operator 2.0 release includes the following new features and enhancements.

Level-2 Operator capabilities

JWS Operator 2.0 provides the following level-2 Operator capability features:

  • Enables seamless upgrades
  • Supports patch and minor version upgrades
  • Manages web servers deployed by the JWS Operator 1.1.x.

Enabling level-2 seamless integration for new images

The Deployment object definition includes a trigger that OpenShift uses to deploy new pods when a new image is pushed to the image stream. The image stream can monitor the repository for new images or you can instruct the image stream that a new image is available for use.

Procedure

  1. In your project namespace, create an image stream by using the oc import-image command to import the tag and other information for an image.

    For example:

    Copy to Clipboard Toggle word wrap 
    oc import-image <my-image>-imagestream:latest \
--from=quay.io/$user/<my-image>:latest \
--confirm

    In the preceding example, replace each occurrence of <my-image> with the name of the image that you want to import.

    The preceding command creates an image stream named <my-image>-imagestream by importing information for the quay.io/$user/<my-image> image. For more information about the format and management of image streams, see Managing image streams.

  2. Create a custom resource of the WebServer kind for the web application that you want the JWS Operator to deploy whenever the image stream is updated. You can define the custom resource in YAML file format.

    For example:

    Copy to Clipboard Toggle word wrap 
    apiVersion: web.servers.org/v1alpha1
kind: WebServer
metadata:
  name: <my-image>
spec:
  # Add fields here
  applicationName: my-app
  useSessionClustering: true
  replicas: 2
  webImageStream:
    imageStreamNamespace: <project-name>
    imageStreamName: <my-image>-imagestream

  3. Trigger an update to the image stream by using the oc tag command.

    For example:

    Copy to Clipboard Toggle word wrap 
    oc tag quay.io/$user/<my-image> <my-image>-imagestream:latest --scheduled

    The preceding command causes OpenShift Container Platform to update the specified image stream tag periodically. This period is a cluster-wide setting that is set to 15 minutes by default.

Level-2 seamless integration for rebuilding existing images

The BuildConfig object definition includes a trigger for image stream updates and a webhook, which is a GitHub, GitLab, or Generic webhook, that enables the rebuilding of images when the webhook is triggered.

For more information about creating a secret for a webhook, see Creating a secret for a generic or GitHub webhook.

For more information about configuring a generic or GitHub webhook in a custom resource WebServer file, see JWS Operator CRD parameters.

Support for Red Hat JBoss Web Server metering labels

JWS Operator 2.0 supports the ability to add metering labels to the Red Hat JBoss Web Server pods that the JWS Operator creates.

Red Hat JBoss Web Server can use the following metering labels:

  • com.company: Red_Hat
  • rht.prod_name: Red_Hat_Runtimes
  • rht.prod_ver: 2025-Q2
  • rht.comp: JBoss_Web_Server
  • rht.comp_ver: 6.1.0
  • rht.subcomp: Tomcat 10
  • rht.subcomp_t: application

You can add labels under the metadata section in the custom resource WebServer file for a web application that you want to deploy. For example:

Copy to Clipboard Toggle word wrap 
---
apiVersion: web.servers.org/v1alpha1
kind: WebServer
metadata:
  name: <my-image>
  labels:
    com.company: Red_Hat
    rht.prod_name: Red_Hat_Runtimes
    rht.prod_ver: 2025-Q2
    rht.comp: JBoss_Web_Server
    rht.comp_ver: 6.1.0
    rht.subcomp: Tomcat 10
    rht.subcomp_t: application
spec:
----
Note

If you change any label key or label value for a deployed web server, the JWS Operator redeploys the web server application. If the deployed web server was built from source code, the JWS Operator also rebuilds the web server application.

Enhanced webImage parameter

In the JWS Operator 2.0 release, the webImage parameter in the CRD contains the following additional fields:

  • imagePullSecret

    The secret that the JWS Operator uses to pull images from the repository

    Note

    The secret must contain the key .dockerconfigjson. The JWS Operator mounts and uses the secret (for example, --authfile /mount_point/.dockerconfigjson) to pull the images from the repository. The Secret object definition file might contain server username and password values or tokens to allow access to images in the image stream, the builder image, and images built by the JWS Operator.

  • webApp

    A set of parameters that describe how the JWS Operator builds the web server application

Enhanced webApp parameter

In the JWS Operator 2.0 release, the webApp parameter in the CRD contains the following additional fields:

  • name

    The name of the web server application

  • sourceRepositoryURL

    The URL where the application source files are located

  • sourceRepositoryRef

    The branch of the source repository that the Operator uses

  • sourceRepositoryContextDir

    The subdirectory where the pom.xml file is located and where the mvn install command must be run

  • webAppWarImage

    The URL of the images where the JWS Operator pushes the built image

  • webAppWarImagePushSecret

    The secret that the JWS Operator uses to push images to the repository

  • builder

    A set of parameters that contain all the information required to build the web application and create and push the image to the image repository

    Note

    To ensure that the builder can operate successfully and run commands with different user IDs, the builder must have access to the anyuid security context constraint (SCC).

    To grant the builder access to the anyuid SCC, enter the following command:

    oc adm policy add-scc-to-user anyuid -z builder

    The builder parameter contains the following fields:

    • image

      The image of the container where the web application is built (for example, quay.io/$user/tomcat10-buildah)

    • imagePullSecret

      The secret (if specified) that the JWS Operator uses to pull the builder image from the repository

    • applicationBuildScript

      The script that the builder image uses to build the application .war file and move it to the /mnt directory

      Note

      If you do not specify a value for this parameter, the builder image uses a default script that uses Maven and Buildah.

Additional resources

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.