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.

Important

Due to a known issue, seamless upgrades do not work properly between versions 2.2 and 2.3 of the JWS Operator. If you have an existing Operator 2.2.x installation, you must first uninstall Operator 2.2.x, as described in JWS Operator deletion from a cluster. Then install the latest Operator 2.3.x version, as described in JWS Operator installation from OperatorHub.

2.1. What is new in the JWS Operator 2.3 release?
Copy link

The JWS Operator 2.3 release includes the following new features, enhancements, and deprecations.

Operator package name change

From JWS Operator 2.3 onward, the package names for the JWS Operator and its respective bundle are changed to jboss-webserver-operator-container-<version> and jboss-webserver-operator-bundle-container-<version>.

This change supersedes the behavior in earlier releases where the package names were jboss-webserver-5-operator-container-<version> and jboss-webserver-5-operator-bundle-container-<version>.

This removal of the JBoss Web Server major version from the package names reflects the fact that the Operator is version-agnostic across different major versions of JBoss Web Server.

New sourceRepositorySecret parameter

JWS Operator 2.3 introduces a sourceRepositorySecret parameter under the webImageStream:webSources hierarchy in the CRD. This parameter specifies the secret for a private repository that contains the application source files.

For more information, see JWS Operator CRD parameters.

Removed Operator responsibility for managing cluster-wide configuration for monitoring system

JWS Operator 2.3 no longer automatically manages the cluster-wide configuration that is required for the cluster monitoring system. From JWS Operator 2.3 onward, users must maintain responsibility for creating this cluster-wide configuration file for monitoring.

For more information, see Management of cluster-wide configuration for monitoring.

Fixed issues
JWS Operator 2.3 includes fixes for various issues that were observed in earlier releases.

2.2. What is new in the JWS Operator 2.2 release?
Copy link

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

New volumeSpec parameter

JWS Operator 2.2 introduces a volumeSpec parameter in the CRD. This parameter specifies the volumes that are to be mounted.

The volumeSpec parameter contains persistentVolumeClaims, secrets, configMaps, and volumeClaimTemplates fields.

For more information, see JWS Operator CRD parameters.

2.3. What is new in the JWS Operator 2.1 release?
Copy link

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

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.4. What is new in the JWS Operator 2.0 release?
Copy link

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

For more information, see Enabling level-2 seamless integration for new images.

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: 2026-Q1
  • rht.comp: JBoss_Web_Server
  • rht.comp_ver: 6.2.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: 

    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: 2026-Q1
    rht.comp: JBoss_Web_Server
    rht.comp_ver: 6.2.0
    rht.subcomp: Tomcat 10
    rht.subcomp_t: application
spec:
    Copy to Clipboard Toggle word wrap
    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.

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

© 2026 Red HatBack to top