In this context, the question is not simply: “Should we replace JBoss EAP?”

The real question is: “How can we modernize these workloads without creating unnecessary risk?”

JBoss EAP still has a future, but its role is changing. It should no longer be seen only as a traditional application server running on long-living virtual machines. Its future is as a supported enterprise Java runtime that can help customers modernize progressively, especially when moving toward OpenShift.

But in large enterprise environments, technology relevance is not measured only by hype. It is measured by stability, supportability, lifecycle, risk, operational maturity, and the ability to run critical workloads for many years.

From that perspective, JBoss EAP still has a future!

Not because every new Java application should be deployed on a traditional application server. That would not be realistic. Its future is different: JBoss EAP remains a strategic runtime for enterprise Java systems that require continuity, long-term support, and controlled modernization.

The future of EAP is linked to application lifecycle, not hype

Many enterprise applications are not replaced every three years. They live for ten, fifteen, sometimes twenty years. They support billing, public administration, banking processes, insurance workflows, logistics, healthcare platforms, or internal business systems.

For these applications, the most important question is not whether the runtime is fashionable. The question is whether the platform remains supportable, secure, upgradeable, and aligned with the enterprise roadmap.

This is where JBoss EAP has value.

Its future will be driven by customers who need a stable enterprise Java platform for existing workloads, not by teams looking for the lightest runtime for a new microservice.

Red Hat’s direction: continuity with modernization

Red Hat’s strategy around JBoss EAP is not to freeze the platform in the past. The move to EAP 8 and Jakarta EE 10 shows that the product continues to follow the evolution of enterprise Java.

This is a major point. Jakarta EE 10 is not just a cosmetic version change. For many customers, it forces a real application review, especially because of the namespace migration from javax.* to jakarta.*, dependency updates, library compatibility, and testing effort.

That means the future of JBoss EAP is not passive. Customers will still need migration projects, compatibility assessments, application testing, dependency cleanup, and platform upgrades.

In parallel, Red Hat also positions EAP in the OpenShift ecosystem, with supported container images and deployment approaches for OpenShift. This confirms that EAP is not limited to the traditional VM model anymore.

The message is clear: JBoss EAP is evolving, but in an enterprise way. It does not try to become Quarkus. It keeps its role as a supported Jakarta EE application platform while becoming more compatible with modern operational models.

The real challenge: reducing dependency on the application server

Some applications depend too much on the application server. Over the years, many systems have accumulated runtime-specific assumptions:

• server-specific modules,
• configuration hidden in the application server,
• hardcoded JNDI names,
• deployment scripts known only by operations teams,
• local filesystem dependencies,
• legacy security mechanisms,
• clustering assumptions,
• old libraries bundled with the application.

These are not only technical details. They are modernization blockers.

A good EAP strategy should therefore not only be “upgrade the server.” It should also reduce unnecessary coupling between the application and the runtime.

The objective is not to leave EAP. The objective is to make the application more portable, more testable, easier to deploy, and less dependent on hidden server configuration.

This is where consulting expertise brings value: identifying which dependencies are legitimate enterprise platform usage, and which ones are accidental complexity created by years of operations.

Conclusion

The future of JBoss EAP is not about competing with every modern Java runtime.

Its future is to remain a reliable enterprise platform for applications that still need the Jakarta EE model, long-term support, and controlled modernization.

At the same time, customers should not ignore Quarkus, Spring Boot, or other modern runtimes. But Quarkus does not replace JBoss EAP in all cases. The right strategy is not to force a single runtime everywhere. The right strategy is to understand the application lifecycle, reduce unnecessary runtime coupling, and choose the platform that matches the workload.

In the future, JBoss EAP will remain strategic wherever enterprise Java continuity, supportability, and risk control matter.

JBoss EAP Blogs

L’article JBoss EAP: From Traditional Application Server to Modern Enterprise Runtime est apparu en premier sur dbi Blog.

The answer is not to rush into a rewrite. In many cases, the most realistic and valuable first step is to move the existing JBoss EAP workloads to OpenShift, while modernizing the way they are built, configured, deployed, monitored, and operated.

This is not a simple lift-and-shift. It is a controlled modernization of the runtime and operating model.

The customer scenario: existing JBoss EAP, new platform expectations

A typical customer already has several applications running on JBoss EAP. Some are packaged as WAR files, others as EAR files. They use datasources, JNDI names, security realms or Elytron, JMS, transactions, batch jobs, custom modules, shared libraries, and sometimes clustering or HTTP session replication.

At the same time, the infrastructure team wants to move to Kubernetes or OpenShift to standardize deployments, improve automation, reduce manual operations, and align with a container-based platform strategy.

In this situation, recommending an immediate migration to another runtime such as Quarkus would often be too aggressive. The customer would have to manage two major changes at the same time: a platform migration and an application architecture migration.

A better approach is to keep JBoss EAP as the first target runtime and move to OpenShift.

Red Hat provides specific documentation for using JBoss EAP on OpenShift, including build and deployment approaches based on Helm charts for EAP 8.x. This matters because the customer is not moving to an unsupported or exotic model. They are moving an existing Red Hat middleware platform into a Red Hat container platform.

Why JBoss EAP still makes sense on OpenShift

JBoss EAP remains a strong choice when the application already depends on enterprise Java capabilities. For existing applications, EAP provides continuity. The customer can keep familiar application patterns which reduce risk compared to a full rewrite.

The real value of OpenShift is not simply “running EAP in a container”. The value comes from changing the operational model.

Instead of manually maintaining application servers on virtual machines, the target model should be:

• One application image per application or application group,
• Configuration externalized through ConfigMaps, Secrets, and environment variables,
• Immutable deployments,
• Health checks and probes,
• Centralized logs,
• Controlled resource requests and limits,
• Automated deployments through CI/CD or GitOps,
• Rolling updates and rollback capability,
• Platform-level security and image governance.

Red Hat documents that EAP applications can be built from compiled WAR or EAR archives and deployed onto a JBoss EAP runtime stack for OpenShift. That is important for real-world migration projects because many customers cannot rewrite their packaging model immediately.

For EAP 7.4 customers, there are also Red Hat-provided OpenShift runtime images, such as the JBoss EAP 7.4 OpenJDK 11 runtime image, described as a base image to run an EAP server and application.

The recommendation should therefore be clear: do not reproduce the old VM model inside Kubernetes. Use the move to OpenShift to clean up the runtime model.

A good migration should review:

• EAP and Java versions,
• WAR/EAR packaging,
• Standalone.xml or domain configuration,
• Datasources and JDBC drivers,
• JMS usage and MDBs,
• Security integration,
• Filesystem dependencies,
• Clustering and session handling,
• JVM tuning,
• Startup and shutdown behavior,
• Logging format;monitoring and alerting,
• CI/CD pipeline,
• Backup and recovery constraints.

Some applications will be easy to containerize. Others will need technical adaptation. A few may not be good candidates without refactoring.

Recommended approach

For a customer already using JBoss EAP, my recommendation is:

Start with JBoss EAP on OpenShift. Stabilize the container model. Then identify which applications or components deserve deeper modernization.

This approach avoids unnecessary risk. It gives the customer a supported and realistic path to Kubernetes while preserving the value of the existing EAP investment.

OpenShift does not automatically make an application cloud-native. The right approach is to understand the existing EAP landscape, modernize the operating model first, and only then decide where a lighter, Kubernetes-native runtime brings measurable value.

Conclusion

In the end, the decision should not be driven by trends, but by application reality: architecture, dependencies, operational constraints, risk, and business value.

If you would like more information or need support with JBoss EAP, from troubleshooting and performance optimization to upgrades and patching, feel free to contact me. I can also support you in assessing and planning the migration of your JBoss workloads to OpenShift or Kubernetes.

L’article Moving JBoss EAP Workloads to OpenShift est apparu en premier sur dbi Blog.

This is not just a documentation tweak or a recommendation shift. It is a hard security enforcement change driven by modern platform standards and compliance expectations from Red Hat.

If you remember only one thing from this article, remember this:

• JBoss EAP 7.4 allows credentials to be defined in multiple ways, including clear text.
• JBoss EAP 8 forces the use of Credential Stores for sensitive resources such as datasources.

JBoss EAP 7.4: Credential Stores were OPTIONAL

In EAP 7.4, Elytron credential stores were already available and recommended, but not enforced.

All of the following were valid and supported:

• Clear-text passwords in standalone.xml
• Encrypted expressions
• Elytron credential-store
• Legacy vault-based approaches (deprecated, but still functional)

A datasource like this was perfectly valid in 7.4:

<datasource jndi-name="java:/jdbc/MyDS" pool-name="MyDS">
    <connection-url>jdbc:postgresql://db:5432/app</connection-url>
    <user-name>app</user-name>
    <password>secret123</password>
</datasource>

JBoss EAP 8: Credential Stores are EFFECTIVELY MANDATORY

With JBoss EAP 8, Red Hat made a clear and intentional decision, sensitive credentials must no longer be stored directly in configuration files.

What changed in practice:

• The element for datasources is no longer the supported approach
• Datasources are expected to use credential-reference
• Elytron is no longer just the default security framework, it is the only one

A valid datasource configuration in EAP 8 looks like this:

<datasource jndi-name="java:/jdbc/MyDS" pool-name="MyDS">
    <connection-url>jdbc:postgresql://db:5432/app</connection-url>
    <user-name>app</user-name>
    <credential-reference store="cs-db" alias="db-password"/>
</datasource>

Why this enforcement exists in EAP 8

This change is not accidental or cosmetic. It aligns EAP with:

• OpenShift and container-native security expectations
• Compliance-driven environments (CIS, ISO, regulated industries)
• Modern “secrets management” practices

“Forced” does not mean “hard”

A common fear when moving to EAP 8 is: “Now everything is complicated” because of security!

In reality, the operational model becomes cleaner and more consistent.

Typical pattern:

1. Create one credential store
2. Add secrets once
3. Reference them everywhere

CLI example:

/subsystem=elytron/credential-store=cs-db:add(
  path=cs-db.jceks,
  relative-to=jboss.server.config.dir,
  credential-reference={clear-text=changeit}
)

/subsystem=elytron/credential-store=cs-db:add-alias(
  alias=db-password,
  secret-value=secret123
)

From that point on:

• No passwords in XML
• No passwords in Git
• No accidental leaks

Migration impact: where most upgrades fail

When upgrading from EAP 7.4 to EAP 8, you must:

• Identify all clear-text credentials
• Move them into credential stores
• Replace <password> with <credential-reference>

This step is mandatory in EAP 8.

Good news:

• If you already used credential stores in 7.4: migration is straightforward
• If you didn’t: EAP 8 forces a long-overdue cleanup

If you’re planning a move to JBoss EAP 8, I can help you get there safely.
From credential-store migration to full security hardening, I support organizations in turning a mandatory change into a controlled, successful upgrade.

L’article JBoss EAP – Credential Stores: from optional best practice to mandatory security baseline est apparu en premier sur dbi Blog.

A Shift Toward Jakarta EE

The most visible and impactful change in JBoss EAP 8 is the transition from Java EE to Jakarta EE.

• Namespace migration: All javax.* packages are now replaced by jakarta.*.
• This means that even if your application compiles fine on EAP 7, it won’t deploy on EAP 8 without updating imports and dependencies.
• While this migration can sound painful, it’s a necessary step to stay compatible with the modern Java ecosystem and future versions of Jakarta EE.

We can count on the Red Hat’s EAP Migration Toolkit to automatically detect and fix most of the package name changes.

New Java and Platform Support

JBoss EAP 8 officially supports Java 17 and later.
This brings performance, security, and syntax improvements, while dropping support for older Java versions (like Java 8 in many cases).

Other platform updates include:

• Updated Undertow web server version for improved HTTP/2 and security.
• Enhanced datasource and driver management via the CLI and management console.
• Simplified configuration through YAML and CLI scripts, helping automate deployments and tuning.

Updated Subsystems and Architecture Improvements

EAP 8 brings a more modular, streamlined architecture:

• Legacy subsystems deprecated (e.g., older messaging or logging frameworks).
• MicroProfile updates: More APIs for observability, configuration, and fault tolerance.
• Improved clustering and domain mode management, faster startup and better node synchronization.

For administrators, these changes mean fewer manual tweaks and more consistent runtime behavior across environments.

Ready for the Cloud (for Real )

Red Hat has made significant investments to make EAP 8 cloud-native:

• Better support for OpenShift and Kubernetes with optimized container images.
• Smaller footprint and faster startup thanks to tuned modules and lazy loading.
• Compatibility with Red Hat build of Quarkus for microservice migration paths.

In other words, JBoss EAP 8 is no longer just a traditional application server, it’s a hybrid platform that bridges the gap between legacy Java EE workloads and modern cloud architectures.

Security and Compliance Enhancements

Security was a major focus in JBoss EAP 8:

• Integrated Elytron 2 for modern authentication and authorization.
• Stronger TLS configurations by default.
• Simplified credential store management (replacing legacy vault mechanisms).

Administrators will appreciate the more centralized, policy-driven security model.

My Experience & Recommendations

After long time working with both JBoss EAP 7 and JBoss EAP 8, I can say the migration is more about preparation than complexity.
The most common pitfalls I’ve seen include:

• Forgetting the Jakarta namespace migration.
• Using old JDBC drivers or libraries no longer supported.
• Missing dependencies when running in containerized environments.

Our best practice is always to:

• Test the migration in a clean environment.
• Use automation (Ansible or CI/CD pipelines) for consistent builds.
• Validate performance, logging, and metrics integration (especially with Zabbix or Elastic).

Once properly prepared, JBoss EAP 8 runs smoother, faster, and integrates much better with modern infrastructure.

Conclusion

JBoss EAP 8 isn’t just an upgrade, it’s a modernization step.
It pushes Java EE into the Jakarta EE era, embraces cloud-native deployments, and simplifies operations for enterprises.
While the migration from EAP 7 requires careful planning, the long-term benefits in performance, maintainability, and compliance make it well worth the effort.

If you’re planning a JBoss migration, feel free to reach out for guidance or a technical exchange.
Have a look at our JBoss EAP blogs for more insights.

Happy to share,

David

L’article From JBoss EAP 7 to 8: What Really Changed est apparu en premier sur dbi Blog.

What is the Credential Store?

Introduced with the elytron subsystem, credential stores allow for secure storage and usage of credentials. As all of the configuration files in (EAP_HOME/standalone/configuration/ and EAP_HOME/domain/configuration/) are world readable by default. It is strongly recommended to not store plaintext passwords in the configuration files, and instead place these credentials in the Credential Store.

Please note all following command are base on JBoss EAP in Standalone mode.

Create a Credential Store

The Credential Store is stored in a file, the place of your choice, you must define the path to this file at creation time. At creation time, you need also to provide the master password that will be used to encrypt the credential store.

/subsystem=elytron/credential-store=dbi_store:add(location="cred_stores/dbi_store.jceks", relative-to=jboss.server.data.dir, credential-reference={clear-text=secretpassword}, create=true)

This CLI command creates a new store named dbi_store, and creates the file jboss.server.data.dir/cred_stores/dbi_store.jceks.

This will implement a default Credential Store, there is a way to implement custom store by adding a module and create a provider loader. To keep this blog readable the custom Credential Store could be shared in a next blog.

Add a credential to Credential Store

Basically, the idea is to store credentials in the Credential Store, so how to add credentials?

The following CLI command adds a credential in a the credential store created before:

/subsystem=elytron/credential-store=dbi_store:add-alias(alias=database-pw, secret-value="my_speci@l_P1$$w0rd_DB")

the alias is the one to be referenced later!

Use the credential stored in the Credential Store

Once the credential is stored in the Credential Store, it is quite easy and secure to refer to it.

In fact, to refer to a sensitive string stored in a credential store, use the credential-reference attribute in the JBoss EAP Configuration, like the following:

credential-reference={store=STORE_NAME, alias=ALIAS}

Fore example, to create a datasource using the password I just added to the credential store dbi_store, I have to execute the following:

data-source add --name=dbi_DS --jndi-name=java:/dbi_DS --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE --user-name=db_user --credential-reference={store=dbi_store, alias=database-pw}

So, instead of providing the password the credential-reference including the store name and alias is provided.
JBoss EAP configured this datasource as following:

/subsystem=datasources/data-source=dbi_DS:read-resource()
{
    "outcome" => "success",
    "result" => {
        ...
        "credential-reference" => {
            "store" => "dbi_store",
            "alias" => "database-pw"
        },
        ...
        "password" => undefined,
        ...
    }
}

Note that the password is undefined and the credential-reference attribute is defined instead.

List the credentials

At any time, you can list the aliases of all credentials contained in a credential store using the following CLI Command:

/subsystem=elytron/credential-store=dbi_store:read-aliases()
{
    "outcome" => "success",
    "result" => [
        "database-pw"
    ]
}

Remove a credential

Well you guess it, you can manage everything via CLI, as any other subsystem. That is why I prefer using Credential Store

So to remove a credential, execute the following command:

/subsystem=elytron/credential-store=dbi_store:remove-alias(alias=database-pw)

Conclusion

You know how to create Credential Store, store and use credentials in a secure way.

IMPORTANT

Please note that it is important to disabled the CLI history before executing commands with passwords. This avoid saving the command and so password in clear text in the CLI History!

history --disable

If you already executed with commands with passwords, it is not too late clear the history asap:

history --clear

Do you need any help? dbi services experts can help you to install and configure JBoss EAP according to Best Practices… Not only JBoss EAP, check the list of Application Servers here.

L’article JBoss EAP – Credential Store est apparu en premier sur dbi Blog.

The sensitive strings can be stored in a keystore, and subsequently decrypted for applications and systems. There is two ways to encrypt sensitive strings outside JBoss EAP configuration files:

• Credential Store
• Password Vault

Please note that even with credential store or password vault, it is recommended to limit the access of configuration files (EAP_HOME/standalone/configuration or EAP_HOME/domain/configuration) to few users.

Let’s understand each one first.

Credential Store

The Credential Store has been introduced in JBoss EAP 7.1 with the elytron subsystem, it can safely secure sensitive and plan text strings by encryption them in a storage file. Each JBoss EAP server can contain multiple credential stores.

The default credential store implementation uses a JCEKS keystore file to store credentials. When creating a new credential store, the default implementation also allows you to reference an existing keystore file or have JBoss EAP automatically create one for you.

Please note that elytron subsystem doesn’t provide any checks for using the same file storage to multiple credential stores, but it is strongly recommended not to use the same file for multiple credential stores.

I will share with you in a next blog how to:

• Create a Credential Store in Standalone and domain mode
• Add a Credential to the Credential Store
• Use the stored Credential in the configuration
• List the Credentials in the Credentials store
• Remove a Credential from a Credential Store

Password Vault

The Password Vault uses the Java Keystore as its storage mechanism. Password vault consists of two parts: storage and key storage. Java keystore is used to store the key, which is used to encrypt or decrypt sensitive strings in Vault storage.

I already explained what is the Password vault and how to use it with example in this blog.

Credential Store vs Password Vault

Well, if you are reading this blog this means that you have probably not yet secured your sensitive strings

Please note that both methods are supported by Red Hat, however, using a Credential Store is preferred to using a Password Vault, because of the following reasons:

• Credential Store allow for easier credential management with the JBoss EAP management CLI, while you need to use an external tool with Password Vault (see blog)
• Using multiple Credential Stores is allowed, while you are limited to only one Password Vault per JBoss EAP server.

So, if you are about to secure your sensitive string, no doubt go with Credential Store. Otherwise, if you are already using Password Vault you have the choice to keep it or migrate your sensitive strings to Credential Store.

I hope that this blog helped you to understand the difference between both, you can now make your choice.

As promised, I will share more details about the Credential Store configuration, so stay connected

L’article JBoss EAP – Credential Store vs Password Vault est apparu en premier sur dbi Blog.

What is the vault password?

The vault encrypts sensitive strings, stores them in an encrypted keystore, and decrypts them for applications and verification systems. To avoid leaving sensitive credentials readable in the standalone.xml or domain.xml files, you can store passwords or other attributes in the vault and then reference the vault from within the server configuration file.

Using a vault creates a level of abstraction and obfuscates data which could otherwise be read by anyone who has access to the configuration files. Please note that the access to the configuration files should be anyway restricted.

Create a Java Keystore to store sensitive strings

The vault utilizes a keystore by using the certificate stored in the keystore as an encryption key for the vault as a whole. To initialize the vault, users need to first create the JavaSE keystore. The following is the syntax used to create a private key, a certificate and to store them in a keystore:

keytool -genseckey -alias <alias> -keyalg <algorithm> -storetype <type> -keysize size -keystore <filepath>

• alias: The alias is a unique identifier for the vault or other data stored in the keystore.
• keyalg: The algorithm to use for encryption.
• storetype: The keystore type. jceks is the recommended type.
• keysize The size of the encryption key which determines the difficulty in brute forcing the
  key.
• keystore: The file path and file name in which the keystore’s values are stored.

The below is an example:

[jboss@vmjboss jboss]# keytool -genseckey -alias vault -keyalg AES -storetype jceks -keysize 128 -keystore /app/jboss/vault.keystore
Enter keystore password:  
Re-enter new password: 
Enter key password for <vault>
	(RETURN if same as keystore password):  

Warning:
The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /app/jboss/vault.keystore -destkeystore /app/jboss/vault.keystore -deststoretype pkcs12".
[jboss@vmjboss jboss]# ls -rtl /app/jboss/
total 4
-rw-r--r-- 1 jboss jboss 500 Sep  4 10:56 vault.keystore

After running the command, you will be prompted for a keystore password and a keystore file will be created at /app/jboss/vault.keystore.

Using the vault

The vault can be initialized either interactively, by providing each parameter one at a time, or by providing all of the parameters initially.

The following is an example of the syntax used to initialize the vault:

vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --vault-block VAULT_BLOCK --attribute ATTRIBUTE --sec-attr SEC-ATTR --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

The following parameters are required to initialize the vault:

• KEYSTORE_URL: The path to the previously created keystore file.
• KEYSTORE_PASSWORD: The password to access the keystore that was used at the keystore’s
  creation.
• SALT: A random string of eight characters used to encrypt the attribute stored in the vault.
• KEYSTORE_ALIAS: The alias that identifies the certificate stored in the keystore.
• ITERATION_COUNT: The number of times encryption is run.
• ENC_FILE_DIR: The path where the encrypted files are stored.
• VAULT_BLOCK: The name to be given to the block in the vault.
• ATTRIBUTE: The name of the attribute being stored. For example, “password” as an attribute
  name when storing a password value.
• SEC-ATTR: The value being stored.

The following is an example with the parameters populated:

[jboss@vmjboss bin]# vault.sh --keystore /app/jboss/vault.keystore --keystore-password password --alias vault --vault-block blog --attribute password --sec-attr blogpass --enc-dir /app/jboss/ --iteration 50 --salt 12345678

After running the vault.sh command, an XML definition of the vault is displayed, which needs to be added to the server configuration files. The following is an example of the XML that needs to be added to either the standalone.xml or host.xml configuration file directly before the section:

<vault>
<vault-option name="KEYSTORE_URL" value="/app/jboss/vault.keystore"/>
<vault-option name="KEYSTORE_PASSWORD" value="MASK-31x/z0Xn83H4JaL0h5eK/N"/>
<vault-option name="KEYSTORE_ALIAS" value="vault"/>
<vault-option name="SALT" value="12345678"/>
<vault-option name="ITERATION_COUNT" value="50"/>
<vault-option name="ENC_FILE_DIR" value="/app/jboss/"/>
</vault>

The final step is to replace the sensitive data with a reference to the attribute in the vault. The vault.sh command provides the exact syntax necessary to reference the secured attribute after all of the parameters are provided. Using the previous example, the vault command generated the following:

VAULT::blog::password::1

In order to use this reference, use the following syntax within the server configuration:

${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::1}

The following can replace the previous password in the server configuration for the blog datasource password:

${VAULT::blog::password::1}

After replacing the password for the datasource, the server configuration for the datasource will look similar to the following:

<datasource jndi-name="java:jboss/datasources/blogope" ...>
<connection-url>...</connection-url>
<driver>mysql</driver>
<security>
<user-name>blogadmin</user-name>
<password>${VAULT::blog::password::1}</password>
</security>
</datasource>

In this blog we saw how to protect passwords or any sensitive data in configuration files. Don’t forget to restrict the access to your configuration files also!

Don’t hesitate to comment this blog, for any question or to share your experience with vault within JBoss EAP.

Some blogs around JBoss EAP:

• JBoss EAP 7 – Modules, Extensions, Subsystems, and Profiles
• JBoss EAP 7 – Domain creation
• JBoss EAP 7 – Cluster in Standalone mode

L’article JBoss EAP 7 – Use vault to protect passwords est apparu en premier sur dbi Blog.

JBoss EAP from RedHat Registry

For JBoss EAP, the best option is to get it from RedHat. To be able to pull image from RedHat registry, we must first register on registry.redhat.io. and create a service account:

Add a name and an option description and click Create. Next screen shows the generated token:

Since I will be using Docker, I select the Docker Login tab, which automatically prepares the command for me to log in to the RedHat registry:

docker login -u='*******|*****' -p=*********...******** registry.redhat.io

Expected output is Login Succeeded.

Then, we are ready to pull the image:

docker pull registry.redhat.io/jboss-eap-7/eap74-openjdk11-runtime-openshift-rhel8:7.4.10-3

This pulls JBoss EAP 7.4 with patch 10 with JDK 11 on RedHat 8:

The image version, 3 in the example above, is the version published by RedHat based on unique combination of other values. They might publish a new image for a given JDK, but not for another.

It is possible to filter existing images using docker search. For example, getting the list of all 7.4 images available on RedHat registry:

$ docker search registry.redhat.io/jboss-eap-7/eap74
NAME                                                  DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
jboss-eap-7/eap74-openjdk17-openshift-rhel8           rhcc_registry.access.redhat.com_jboss-eap-7/…   0
jboss-eap-7/eap74-openjdk8-openshift-rhel7            JBoss EAP 7.4 with OpenJDK8                     0
jboss-eap-7/eap74-openjdk11-openshift-rhel8           JBoss EAP 7.4 with OpenJDK11                    0
jboss-eap-7/eap74-openjdk17-runtime-openshift-rhel8   rhcc_registry.access.redhat.com_jboss-eap-7/…   0
jboss-eap-7/eap74-openj9-11-openshift-rhel8           JBoss EAP 7.4 with OpenJDK11 + OpenJ9           0
jboss-eap-7/eap74-openjdk11-runtime-openshift-rhel8   JBoss EAP 7.4 with OpenJDK11 (Runtime Image)    0
jboss-eap-7/eap74-openjdk8-runtime-openshift-rhel7    JBoss EAP 7.4 with OpenJDK8 (Runtime Image)     0
jboss-eap-7/eap74-openj9-11-runtime-openshift-rhel8   JBoss EAP 7.4 with OpenJDK11 + OpenJ9 (Runti…   0

WildFly on Quay.io

Quay is a container registry hosted by RedHat and could also be deployed on premises. We will pull WildFly image from Quay. As it does not require any login and will be a straightforward process:

docker pull quay.io/wildfly/wildfly:27.0.1.Final-jdk11

Comparably to JBoss EAP pull command, we can know the version we are getting:

• 27.0.1 is WildFly version
• jdk11 is JDK version

Running the Image

Wait, in JBoss EAP, we only pulled the image and did not run it. Let’s do it for WildFly.

docker run quay.io/wildfly/wildfly:27.0.1.Final-jdk11

Partial output:

...
09:40:51,946 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on 0.0.0.0:8080
09:40:52,327 INFO  [org.jboss.as.ejb3] (MSC service thread 1-5) WFLYEJB0493: Jakarta Enterprise Beans subsystem suspension complete
09:40:52,400 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTPS listener https listening on 0.0.0.0:8443
09:40:52,405 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-6) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/jboss/wildfly/standalone/deployments
09:40:52,416 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
09:40:52,498 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
09:40:52,576 INFO  [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBossWS 6.1.0.Final (Apache CXF 3.5.2.jbossorg-4)
09:40:52,757 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
09:40:52,761 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 27.0.1.Final (WildFly Core 19.0.1.Final) started in 5410ms - Started 290 of 563 services (357 services are lazy, passive or on-demand) - Server configuration file in use: standalone.xml
09:40:52,764 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
09:40:52,764 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990

This is nice and quick, but why can’t I access this URL? If I am checking netstat -lnp output, I will not see anything binding on 9990 despite what log says. This is because I forgot to expose port outside of the container (i.e. the host), so let’s modify the command:

docker run -p 9990:9990 quay.io/wildfly/wildfly:27.0.1.Final-jdk11

Despite this change, I can’t still access the administration console. This time, it is because, by default, WildFly does not bind it to external IP of server (container in this example), thus we have to tune docker command further. Here it will not be docker specific argument, but WildFly:

docker run -p 9990:9990 quay.io/wildfly/wildfly:27.0.1.Final-jdk11 /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0

Now, we are prompted for credentials which means it is up, but I can’t find the credentials anywhere.

Building a Custom Container Image

Docker defined a file format to be able to extend an existing image. As the aim of an application server like WildFly is to run web application, additionally to setup an administrator account, we will deploy one web application. Dockerfile will look like:

FROM quay.io/wildfly/wildfly:27.0.1.Final-jdk11
RUN /opt/jboss/wildfly/bin/add-user.sh admin ********
ADD helloworld.war /opt/jboss/wildfly/standalone/deployments/
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

The explanation of each line:

1. FROM: The source docker image
2. RUN: A command run which will modify the image
3. ADD: Copy a local file into the image
4. CMD: Container starting command with arguments. This will make our docker command shorter.

To build the image, I am running docker build --tag=wildfly-web-app . in the directory where Dockerfile is stored (note the extra point at the end of the command):

[+] Building 1.8s (8/8) FINISHED
 => [internal] load .dockerignore                                                                                                                                                                                                      0.1s
 => => transferring context: 2B                                                                                                                                                                                                        0.0s
 => [internal] load build definition from Dockerfile                                                                                                                                                                                   0.1s
 => => transferring dockerfile: 200B                                                                                                                                                                                                   0.0s
 => [internal] load metadata for quay.io/wildfly/wildfly:27.0.1.Final-jdk11                                                                                                                                                            0.0s
 => [1/3] FROM quay.io/wildfly/wildfly:27.0.1.Final-jdk11                                                                                                                                                                              0.1s
 => [internal] load build context                                                                                                                                                                                                      0.1s
 => => transferring context: 74.39kB                                                                                                                                                                                                   0.0s
 => [2/3] RUN /opt/jboss/wildfly/bin/add-user.sh admin admin                                                                                                                                                                           1.4s
 => [3/3] ADD helloworld.war /opt/jboss/wildfly/standalone/deployments/                                                                                                                                                                0.1s
 => exporting to image                                                                                                                                                                                                                 0.1s
 => => exporting layers                                                                                                                                                                                                                0.1s
 => => writing image sha256:e3d58dc0ebe2554ce7f9e5e7da2a5483c7e7c6801159ec05a45c5d66577c46d9                                                                                                                                           0.0s
 => => naming to docker.io/library/wildfly-web-app

Now, I have a new docker image available:

REPOSITORY                        TAG                  IMAGE ID       CREATED          SIZE
wildfly-web-app                   latest               e3d58dc0ebe2   33 seconds ago   848MB

Let’s run it with an additional exposed port for the web app:

docker run -p 9990:9990 -p 8080:8080 wildfly-web-app

It is up and ready:

With a deployed web application:

My Opinion

Even if these pre-built images are nice, we must extend them in a way or another, thus I prefer to use YaK to deploy and configure ready to use servers with our best practices already embedded.

L’article JBoss-EAP and WildFly Official Docker Images est apparu en premier sur dbi Blog.

It’s worth noting that RedHat does not offer newer versions of JBoss EAP that come with patches pre-installed, so all new installations must be patched (at least for major versions).

Global Availability Version

In my fresh installation of JBoss-EAP, I starts jboss-cli.sh (without connecting to a server) and verify the version:

[disconnected /] version
JBoss Admin Command-line Interface
JBOSS_HOME: C:\Users\ols\Documents\Technical\JBoss\Installers\jboss-eap-7.4
Release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: C:\Installations\jdk11.0.16_9
java.version: 11.0.16.1
java.vm.vendor: Amazon.com Inc.
java.vm.version: 11.0.16.1+9-LTS
os.name: Windows 10
os.version: 10.0

I can also confirm the patching level with command patch info:

Version:             7.4.0.GA
Cumulative patch ID: base
One-off patches:     none

Patching

Still in cli, the command is as simple as patch apply <path-to-zip>. For the example below, we will patch with jboss-eap-7.4.10-patch.zip:

[disconnected /] patch apply ../../jboss-eap-7.4.10-patch.zip
{
    "outcome" : "success",
    "result" : {}
}

Followed by a patch info to confirm the version:

Version:             7.4.10.GA
Cumulative patch ID: jboss-eap-7.4.10.CP
One-off patches:     none

It is also possible to list all patches installed with patch history:

{
    "outcome" : "success",
    "result" : [{
        "patch-id" : "jboss-eap-7.4.10.CP",
        "type" : "cumulative",
        "applied-at" : "03/04/2023 16:47",
        "aged-out" : false
    }]
}

If server is running, do not forget to restart after patching with reload.

What About Rollback?

You probably guessed it, at this point, to rollback, we must provide the patch-id:

[disconnected /] patch rollback jboss-eap-7.4.10.CP
Option: --reset-configuration is required for this command.

Wait, it did not rollback. Why? Because, we must decide if we want to keep the currently running configuration or want to rollback it at the time the patching has been done. Two options exist:

• If no configuration changes were done since patch was applied, there is no risk to rollback configuration along with binaries.
• If there were configuration changes, there is a risk for inconsistency between configuration and running modules. Testing is necessary even if the risk is low.

Impact on Directory Structure

A patch contains following files:

The XML files contain a description of what needs to be patched. Folders contain binaries and are as follow:

1. jboss-eap-7.4.10.CP contains all files that are not modules
2. layer-base-jboss-eap-7.4.10.CP contains similar structure as in modules directory of JBoss installation

Thus, when installing a patch file, it will not be applied the same way.

For modules (point 2), patching will consist of a simple copy of the folder under modules\system\layers\base\.overlays plus creation of a .overlays directory. Files under that directory will take precedence when server will start which means if this directory is altered patching might be broken.

For other binaries (point 1), patching will consist of backing up files to patch under .installation directory (keeping directory structure) at root of JBoss home directory.

Why speaking about that? Because some tools like dependency-check will continue to report component vulnerabilities after patching as either patched files are backup in .information directory or they stay in modules directory. This is the reason why the results of these types of tools must be carefully and thoroughly analyzed.

L’article JBoss EAP Patching est apparu en premier sur dbi Blog.

Metrics

Fortunately, WildFly comes with a integrated metrics subsystem which is included in all out-of-the-box profiles.

In the management console, we can go in subsystem and then metric menu to access settings:

There are not many parameters, but I will not complain. By default, all subsystems’ metrics are exposed with wildfly as prefix and without any security restriction.

So let’s confirm metrics are exposed by accessing metrics URL (http://<hostname>:9990/metrics):

# HELP base_classloader_loadedClasses_total Displays the total number of classes that have been loaded since the Java virtual machine has started execution.
# TYPE base_classloader_loadedClasses_total counter
base_classloader_loadedClasses_total 21584.0
# HELP base_classloader_loadedClasses_count Displays the number of classes that are currently loaded in the Java virtual machine.
# TYPE base_classloader_loadedClasses_count gauge
base_classloader_loadedClasses_count 21433.0
# HELP base_classloader_unloadedClasses_total Displays the total number of classes unloaded since the Java virtual machine has started execution.
# TYPE base_classloader_unloadedClasses_total counter
base_classloader_unloadedClasses_total 151.0
# HELP base_cpu_availableProcessors Displays the number of processors available to the Java virtual machine. This value may change during a particular invocation of the virtual machine.
# TYPE base_cpu_availableProcessors gauge
base_cpu_availableProcessors 2.0
# HELP base_cpu_processCpuLoad Displays the "recent cpu usage" for the Java Virtual Machine process.
# TYPE base_cpu_processCpuLoad gauge
base_cpu_processCpuLoad 0.01848998459167951
...

We are ready to integrate it into Prometheus.

Prometheus Integration

To achieve that, we will edit Prometheus configuration file (i.e. prometheus.yml) and add a new job:

scrape_configs:
  - job_name: 'metrics'
    scrape_interval: 15s
    static_configs:
      - targets: ['hostname:9990']

Then, we can start our Prometheus server and confirm if metrics are gathered properly. For that, go on http://prometheus:9090/ and browse to Status and then Targets:

You should see the WildFly endpoint in the list with a “UP” state:

Even if all subsystems are exposed, that does not necessarily mean everything in the subsystem is exposed. For example, I have a JDBC data source declared in my configuration, but I can’t find any metrics in the list. This has to be enabled on per data source basis.

Default state (Statistics Enabled = false):

Click “Edit” and switch statistics ON:

This can also be done with jboss-cli command:

/subsystem=datasources/data-source=:write-attribute(name=statistics-enabled,value=true)

Now, refresh WildFly metrics web page to see the new metrics:

...
# HELP wildfly_datasources_pool_active_count The active count
# TYPE wildfly_datasources_pool_active_count gauge
wildfly_datasources_pool_active_count{data_source="OracleDS"} 1.0
# HELP wildfly_datasources_pool_available_count The available count
# TYPE wildfly_datasources_pool_available_count gauge
wildfly_datasources_pool_available_count{data_source="OracleDS"} 20.0
# HELP wildfly_datasources_pool_average_blocking_time Average Blocking Time for pool
# TYPE wildfly_datasources_pool_average_blocking_time gauge
wildfly_datasources_pool_average_blocking_time{data_source="OracleDS"} 0.0
# HELP wildfly_datasources_pool_average_creation_time The average time spent creating a physical connection
# TYPE wildfly_datasources_pool_average_creation_time gauge
wildfly_datasources_pool_average_creation_time{data_source="OracleDS"} 3138.0
# HELP wildfly_datasources_pool_average_get_time The average time spent obtaining a physical connection
# TYPE wildfly_datasources_pool_average_get_time gauge
wildfly_datasources_pool_average_get_time{data_source="OracleDS"} 652.0
# HELP wildfly_datasources_pool_average_pool_time The average time for a physical connection spent in the pool
# TYPE wildfly_datasources_pool_average_pool_time gauge
wildfly_datasources_pool_average_pool_time{data_source="OracleDS"} 5890.0
# HELP wildfly_datasources_pool_average_usage_time The average time spent using a physical connection
# TYPE wildfly_datasources_pool_average_usage_time gauge
wildfly_datasources_pool_average_usage_time{data_source="OracleDS"} 4.0
...

There are similar settings for almost all subsystems like, for example, undertow the web server part:

/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)

What’s Next?

Then, it is just a matter of configuring Grafana to query Prometheus and add metrics in dashboards:

A similar method can be applied to JBoss EAP.

L’article WildFly monitoring in Prometheus est apparu en premier sur dbi Blog.