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.

However, they are often monitored like basic infrastructure components: CPU, memory, disk, process status, and sometimes port availability. This is useful, but it is not enough.

An application server can be up, the JVM can be running, and the port can respond, while users are already experiencing slow response times, blocked transactions, JDBC pool saturation, session issues, or intermittent application errors.

This is where observability brings real value. The objective is not only to know whether the server is alive. The objective is to understand how the application behaves, where it is degraded, and what needs to be fixed first.

Application servers are not just Java processes

A common mistake is to monitor application servers as if they were simple JVMs.

In reality, an application server is an execution platform. It manages applications, HTTP requests, sessions, datasources, connection pools, transactions, security, messaging, classloading, thread pools, integrations, and sometimes clustering.

When an incident happens, the root cause is rarely visible from CPU and memory alone.

A production issue can come from:

• a saturated JDBC pool,
• slow database queries,
• blocked or waiting threads,
• excessive garbage collection,
• a failing backend service,
• too many HTTP sessions,
• deployment-related errors,
• authentication or authorization failures,
• JMS queue backlog.

Traditional monitoring can tell us that something is wrong. But it often cannot explain why.

This is the gap Elastic Observability can help to close.

Elastic Observability brings together logs, metrics, traces, and application performance data in a unified platform. Elastic documents its observability solution as combining logs, metrics, application traces, user experience data, and synthetic monitoring in order to provide visibility across applications and infrastructure.

For application servers, this matters because troubleshooting is rarely based on one signal. A slow application transaction may require looking at the HTTP request, Java method execution, database call, connection pool behavior, JVM metrics, and server logs at the same time.

The real problem is fragmented troubleshooting

In many middleware environments, the data already exists but it is fragmented.

Logs are on one server. JVM metrics are in another tool. Thread dumps are collected manually. Database metrics are owned by another team. Application errors are visible only to developers. Infrastructure alerts are managed by operations. APM, if present, may not be correlated with platform logs.

During an incident, teams lose time switching between tools, comparing timestamps, grepping logs, opening server consoles, requesting database checks, and trying to reconstruct the sequence of events manually.

This is especially true for application servers, because they sit between multiple domains:

• application code,
• JVM configuration,
• database,
• messaging,
• identity provider,
• network,
• external APIs,
• container or VM platform.

The application server is often where the symptoms appear, but not always where the root cause is.

A typical example is a slow application. The server is up. CPU is normal. Memory is acceptable. But users complain.

Without observability, the investigation may start with generic checks: server status, JVM memory, recent logs, database availability, thread dumps, and maybe application team escalation.

With proper observability, the investigation can start from the user-facing symptom:

• Which endpoint is slow?
• Since when?
• Is it all users or only one application flow?
• Is the latency inside the Java application?
• Is it caused by a database call?
• Is the JDBC pool waiting?
• Is an external HTTP call slow?
• Did errors increase after a deployment?
• Are logs showing the same transaction or correlation ID?

Elastic APM is designed to collect performance information such as response times, database queries, cache calls, external HTTP requests, and related application behavior, helping to identify performance issues more quickly.

That changes the troubleshooting model. Instead of starting from the server and searching for a symptom, teams can start from the degraded service and follow the evidence.

Elastic does not replace middleware expertise, it amplifies it

Elastic Observability is not magic, and it does not remove the need for application server expertise. An expert still needs to understand what matters in WebLogic, JBoss EAP, WildFly, Tomcat, or WebSphere.

The value of Elastic is to make this expertise operational.

Elastic supports both its own APM agents and OpenTelemetry-based collection. Elastic documentation states that OpenTelemetry can be used to collect application performance data in Elastic APM across serverless, self-managed, and hybrid deployments. This is important for enterprise environments because you may not want to lock instrumentation strategy to a single vendor-specific approach.

In any case, a serious observability implementation should therefore start with an assessment, not with agent installation only.

For application servers, I would typically define:

• which applications are critical,
• which logs must be collected,
• which JVM and OS metrics are required,
• which application transactions need tracing,
• whether APM agent or OpenTelemetry is the best option,
• which technical indicators matter: response time, error rate, GC, threads, JDBC pool, JMS backlog, deployment events,
• which business indicators matter: failed orders, failed logins, slow reports, blocked workflows,
• which alerts are useful and which ones will create noise.

The goal is not to collect everything. The goal is to collect the right signals and correlate them.

Conclusion

Application servers remain critical in enterprise IT, but traditional monitoring is no longer enough. Knowing that a JVM is running, CPU and memory are normal, or a port is open does not explain where a performance issue actually starts.

For platforms such as WebLogic, JBoss EAP, WildFly, Tomcat, and WebSphere, real observability comes from correlating logs, metrics, traces, and application behavior.

Elastic Observability provides this visibility, helping teams move from basic monitoring to faster and more effective troubleshooting.

The real value, however, comes from combining the technology with the right expertise. Our teams bring together strong Elastic, application-server, and database expertise, enabling us to implement observability solutions that collect the right signals, provide meaningful insights, and accelerate root cause analysis.

Ultimately, observability is not about dashboards. It is about reducing blind spots, shortening incident resolution, and giving teams a shared view of production reality.

L’article Elastic Observability for Application Servers: From Monitoring to Troubleshooting Intelligence 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.