Yet report generation failed.

Even a simple request to display the Reports job list returned an error:

REP-50125: An internal exception occurred:
java.security.PrivilegedActionException:
javax.security.auth.login.LoginException:
java.lang.NoClassDefFoundError:
Could not initialize class
oracle.security.jps.service.policystore.info.BuiltInFunctionsHandler

The investigation led somewhere else: a Reports Server JVM running with a maximum heap of only 256 MiB, while the equivalent environment used 1 GiB.

Here is how we moved from a misleading symptom to an evidence-based diagnosis.

Separate process availability from application health

The initial service check showed every component as running:

AdminServer             is running.
WLS_REPORTS             is running.
RptSvr_app-dev_1         is running.
RptSvr_app-dev_2         is running.

This established that the processes existed. It did not establish that they could authenticate requests, evaluate security policies, or execute reports.

The failing showjobs request provided a more useful functional check. It showed that Reports could receive a request but failed while processing it.

The first lesson is straightforward:

A running process is an infrastructure observation, not an application health check.

Find the first exception, not the most frequently repeated one

The browser displayed:

NoClassDefFoundError: Could not initialize class ...

The wording matters. A class that cannot initialize is not necessarily a missing class.

I searched the Reports Server diagnostic logs for the first occurrence and the exceptions preceding it:

grep -n -B 30 -A 70 -E \
  'BuiltInFunctionsHandler|ExceptionInInitializerError|OutOfMemoryError|Caused by:' \
  rwserver_diagnostic.log

Earlier in the same process lifetime, the log contained:

ava.lang.OutOfMemoryError: GC overhead limit exceeded
...
oracle.security.jps.service.policystore.info.BuiltInFunctionsHandler.<clinit>

The sequence was now clear:

• The JVM encountered memory exhaustion during initialization of a security class.
• That initialization failed.
• Subsequent requests reported that the class could not initialize.

The security error was therefore a consequence of the earlier memory failure.

The first exception explained the incident; the later exceptions described its persistent symptoms.

Identify the JVM that actually failed

An Oracle Reports installation involves several processes with different responsibilities:

Each can have its own JVM configuration.

Increasing the heap of WLS_REPORTS would not necessarily help a failure occurring inside the standalone rwserver process.

I first mapped the processes:

ps -ww -eo pid,user,rss,args |
  grep -E '[b]in/rwserver|[w]eblogic.Name=WLS_REPORTS|[o]racle.reports.engine.RWEngine'

Then I checked which JVM library the affected native rwserver process had loaded:

grep 'libjvm.so' /proc/<REPORTS_PID>/maps

This revealed another useful detail: the JVM loaded from the Oracle home differed from the JDK referenced by JAVA_HOME.

The Reports startup script populated LD_LIBRARY_PATH with the bundled JVM location.

That distinction did not prove a Java compatibility problem. It established which JDK tools we should use and prevented us from diagnosing the wrong runtime.

For a running process, inspect what is loaded not just what the shell environment suggests.

Measure the heap instead of inferring it from available RAM

The operating system reported more than 20 GiB of available memory.

That did not contradict the Java memory error. A JVM can exhaust its configured heap while the host still has substantial free RAM.

Using the matching JDK, I inspected the effective JVM flags:

"$REPORTS_JDK/bin/jcmd" <REPORTS_PID> VM.flags

The relevant output was:

-XX:InitialHeapSize=268435456
-XX:MaxHeapSize=268435456

The maximum heap was 256 MiB.

Next, I sampled garbage collection statistics:

"$REPORTS_JDK/bin/jstat" -gcutil <REPORTS_PID> 1000 10

The affected process showed:

The Full GC counter did not increase during that short sample. However, the nearly full heap, accumulated collection activity, and recorded OutOfMemoryError together provided strong evidence of heap exhaustion.

A single memory percentage would have been insufficient. The diagnosis came from combining the logs, effective configuration, and runtime measurements.

Compare with a working environment

I inspected the environment inherited by the working process:

tr '\0' '\n' < /proc/<REPORTS_PID>/environ |
  grep -E '^(REPORTS_JVM_OPTIONS|JAVA_TOOL_OPTIONS|_JAVA_OPTIONS)='

The reference environment contained:

REPORTS_JVM_OPTIONS= -Xmx1024M

Comparing the Reports environment scripts then revealed the missing lines in the affected domain’s reports/bin/reports.sh:

REPORTS_JVM_OPTIONS=" -Xmx1024M"
export REPORTS_JVM_OPTIONS

Validate the correction

The client aligned the Reports memory configuration with the reference environment and subsequently confirmed that report generation and application checks worked again.

A separate question remained: why had the problem become visible after this particular operating system upgrade and restart?

We did not have the previous process’s effective heap settings or a historical memory profile. We therefore could not prove whether the restart changed the inherited environment, whether memory demand had increased, or whether another condition exposed an existing limitation.

The timing made the OS upgrade a reasonable starting hypothesis. It did not make it the demonstrated root cause.

Conclusion

This incident followed a useful progression. The most valuable habit was to follow the evidence backward, from the visible error to the first failure, and then forward again, from the configuration difference to a verified recovery.

When critical applications stop working, you need more than a restart… You need a team that understands the platform. At dbi services, our Service Desk combines responsive support with deep technical expertise to investigate incidents, identify their causes, and guide recovery with clear, evidence-based recommendations.

Looking for expert support for your Oracle Fusion Middleware environment? Contact us to discuss how we can help.

More related blogs

L’article Oracle Reports: REP-50125: An internal exception occurred est apparu en premier sur dbi Blog.

These discussions usually involve critical environments based on Oracle WebLogic Server, Oracle Forms, and sometimes Oracle Reports. The objective is rarely just to “move to the cloud”. It is about understanding what can realistically be migrated, what should be modernized, what must be validated, and where the main technical, operational, and licensing risks are.

Based on these discussions, I would like to share a few practical considerations that may be useful when evaluating a cloud migration strategy for Oracle Fusion Middleware workloads.

Lift and shift is not a shortcut, it is a controlled migration strategy

For Oracle WebLogic, Forms and Reports platforms, a cloud migration should not automatically be presented as an application modernization project.

In many cases, the first realistic step is a lift-and-shift migration. The goal is not to rewrite Forms modules, redesign the full application, or replace every legacy component immediately. The goal is to rebuild a controlled target platform in the cloud while preserving the application behavior as much as possible.

However, lift and shift does not mean copying virtual machines and hoping that everything will work.

A serious migration requires a detailed comparison between the existing platform and the target one: WebLogic domain configuration, Managed Servers, Datasources, Wallets, Certificates, JVM version, Patch level, Forms runtime configuration, Reports configuration, File system dependencies, Fonts, Printers, Batch jobs, Monitoring, Backup, Restart procedures, and Operational scripts.

Oracle documents several WebLogic migration approaches to OCI, including manual deployment, WebLogic Deploy Tooling, and WLST-based deployment scripts targeted to a new domain. Oracle also describes WebLogic Server for OCI as a way to provision a WebLogic domain in OCI more quickly than a traditional on-premises setup.

This is why lift and shift should be seen as an engineering exercise, not as a low-effort infrastructure move.

Why OCI is naturally aligned with Oracle Fusion Middleware

It would not be accurate to say that Oracle Fusion Middleware can only run on OCI. Oracle’s own cloud licensing policy lists AWS, Azure, and Google Cloud Platform as “Authorized Cloud Environments” for specific Oracle software licensing rules. The same policy also explains how vCPUs must be counted in these environments and states that the Oracle Processor Core Factor Table is not applicable there.

So the real point is not that other clouds are impossible. The point is that OCI is naturally aligned with Oracle Fusion Middleware workloads.

For WebLogic, Oracle provides OCI-specific deployment models, Marketplace-based options, and documented migration patterns. For Kubernetes-based deployments, Oracle also documents WebLogic Server for OKE using a Marketplace stack, including lifecycle-management components such as Jenkins and the WebLogic Kubernetes Operator.

From an operational and licensing perspective, OCI also gives Oracle customers options such as BYOL and Universal Credits-based models. Oracle’s Support Rewards FAQ states that BYOL services on the Universal Credits Model rate card are eligible for the Support Rewards program.

This does not remove the need for a proper license review. But it does mean that for Oracle middleware workloads, OCI often provides a more Oracle-native discussion: infrastructure, middleware, licensing, support model, and target architecture can be addressed within the same ecosystem.

Oracle Reports must be treated as a specific risk

For Oracle Forms and WebLogic, a structured lift-and-shift approach to OCI can be a realistic option. For Oracle Reports, the discussion must be more careful.

Oracle Reports is still present in many enterprise Forms platforms, but it has technical characteristics that must be validated before any cloud migration. Reports cluster members or clients use multicast to discover other nodes, and that there is no workaround for using multicast in that context.

This is a critical point because multicast is generally not available in all cloud network architectures.

In practical terms, Oracle Reports should not be treated as a simple checkbox in the migration plan. It requires a dedicated technical validation: Reports Server configuration, naming service, generated output, cache behavior, fonts, printers, file paths, batch execution, restart behavior, and integration with the Forms application.

Conclusion

The conclusion is therefore simple: WebLogic and Forms can be good candidates for a controlled lift-and-shift migration to OCI. Oracle Reports must be assessed separately, tested carefully, and challenged architecturally.

OCI can reduce complexity for Oracle Fusion Middleware migrations, but it does not remove the need for deep product expertise. A successful migration is not only a cloud project, it is a WebLogic, Forms, Reports, licensing, operations, and validation project.

If you are planning to migrate an Oracle Fusion Middleware platform to the cloud, or if you simply want to assess whether such a migration is realistic for your environment, feel free to contact me. I would be happy to help you challenge the architecture, identify the risks, and define a pragmatic migration approach.

More related blogs here.

L’article Oracle Fusion Middleware to the Cloud est apparu en premier sur dbi Blog.

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.

Yet modern distributed systems introduced a shift in mindset: monitoring is no longer enough. Enter observability, not as a buzzword, but as an operational necessity.

This blog explains the difference clearly, with practical engineering examples and a real-world perspective.

Monitoring: Knowing When Something Is Wrong

Traditional monitoring answers a very specific set of questions:

• Is the service up?
• Are resources within acceptable limits?
• Are error rates crossing thresholds?
• Are we respecting SLAs?

Monitoring is fundamentally about predefined signals.

What Monitoring Does Well

Monitoring excels at:

• Incident detection
• Alerting and operational response
• Capacity tracking and trend analysis
• Infrastructure health visibility

Example: Classic Monitoring Workflow

You monitor an API using:

• Prometheus metrics (http_requests_total, latency histograms)
• Grafana dashboards
• Alert rule: 5xx error rate > 2% for 5 minutes

You immediately know something is wrong. But the next question appears: Why is it wrong?

And this is where traditional monitoring starts to hit limits.

The core limitation

Monitoring depends on:

• Metrics you anticipated
• Thresholds you defined in advance
• Scenarios you already imagined

When failures fall outside those assumptions, which is common in distributed systems, troubleshooting becomes exploratory and slow.

Observability: Understanding Why Something Is Wrong

Observability is not just more dashboards. It is the ability to understand internal system behavior from external outputs, even when you don’t already know what to look for.

Instead of asking: “Is the system healthy?”

Observability lets you ask:

• Why are users experiencing latency?
• Which service introduced the regression?
• What changed right before the incident?
• Which request path is affected?

This is a fundamentally different operational capability.

Modern observability relies on correlated telemetry:

• Metrics – aggregated system behavior
• Logs – detailed contextual events
• Traces – end-to-end request journeys

Individually, they are useful. Together, they provide causal understanding.

Practical Evolution: From Monitoring to Observability

You don’t replace monitoring, you evolve it. A pragmatic path:

1. Define meaningful metrics
   Focus on user-centric signals: latency, traffic, errors, saturation.
2. Structure logs properly
   Include fields like service, environment, trace_id, deployment_version.
3. Instrument distributed tracing
   Start with critical journeys (checkout, authentication, search).
4. Enable cross-linking
   Alert -> metric -> trace -> logs must be one flow.
5. Shift toward SLO-based thinking
   Alert on user impact, not raw CPU.

Conclusion

Observability isn’t about collecting more data, it’s about turning telemetry into understanding.

And that is where mature engineering organizations truly differentiate themselves: not by how much they monitor, but by how quickly and confidently they can understand, diagnose, and resolve complex system behaviors in production.

If your organization is starting this journey or aiming to accelerate its maturity, we would be happy to help. From strategy and tooling selection to implementation and operational enablement, feel free to reach out and connect with us.

Related blogs : Zabbix, monitoring, Elastic

L’article Observability vs Monitoring 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.

I found it a very good question. From the user’s perspective, both methods look similar: the Forms application opens in its own Java window. The real difference is how the application is launched, deployed, secured, and maintained on the workstation.

Here is the practical answer, based on experience with Oracle Forms environments.

First, both methods use the same Forms architecture

Whether you use Java Web Start or FSAL:

• The Forms application remains hosted centrally on the application server.
• The .fmx, .mmx, and .plx modules stay on the server.
• A Java-based Forms client runs on the user’s workstation.
• The client communicates with Oracle Forms Services, generally hosted on WebLogic Server.
• The application itself normally does not need to be rewritten when changing the launch method.

Therefore, FSAL is not a return to the old Forms 6i client/server architecture. It only provides a similar desktop experience,

Java Web Start

Java Web Start, or JWS, launches the application using a JNLP file.

The user normally opens a Forms URL:

https://forms.example.com/forms/frmservlet?config=webstart

The server generates a .jnlp file, which is downloaded and opened by Java Web Start. The Forms application then runs in a separate Java window.

Oracle describes Java Web Start as a semi-browserless configuration: the browser can be used to initiate the application, but the application does not run inside the browser window.

Advantages of Java Web Start

• Users can start the application from a familiar web link.
• The JNLP configuration is generated centrally by the Forms server.
• Java archives can be downloaded and cached automatically.
• It can integrate well with environments where authentication starts in the browser.
• It usually requires limited change when replacing an older browser-based Forms deployment.

Disadvantages of Java Web Start

• It depends on Java Web Start technology, which is associated mainly with Java 8.
• Java Web Start is no longer included in modern JDK releases.
• JNLP file associations can behave differently depending on the workstation and browser.
• Browser security settings may prevent the JNLP file from opening automatically.
• Java cache problems are relatively common.
• Certificate changes, proxies, and local Java security settings can affect application startup.
• Troubleshooting frequently involves the user’s workstation rather than the Forms server.

My experience with Java Web Start

Once correctly configured, Java Web Start works well. However, many operational incidents are related to the client environment:

• The .jnlp file is downloaded but not opened.
• The workstation uses the wrong Java version.
• The operating system loses the JNLP file association.
• An old JAR remains in the Java cache.
• A certificate renewal causes a new security warning.
• Browser updates change how downloaded JNLP files are handled.

These are rarely Forms application problems, but they still generate support requests.

When should you choose Java Web Start?

Java Web Start remains reasonable when:

• The organization already has a stable and managed Java 8 environment.
• The existing JWS deployment works reliably.
• Users need to launch Forms from a browser-based portal.
• The authentication or SSO process requires a browser.
• The objective is a short-term migration with minimal client-side change.

I would be more cautious about selecting JWS for a completely new, long-term deployment because of its dependency on legacy Java deployment technology.

Forms Standalone Launcher

The Forms Standalone Launcher, or FSAL, launches Oracle Forms without relying on a browser or Java Web Start.

The workstation runs the frmsal.jar launcher directly:

java -jar frmsal.jar -url "https://forms.example.com/forms/frmservlet?config=standaloneapp"

In practice, users do not need to enter this command. It can be included in a desktop shortcut, shell script, batch file, or software deployment package.

Advantages of FSAL

• It is fully independent of the browser.
• It does not require Java Web Start or a browser plug-in.
• It provides a clean desktop application experience.
• Browser updates do not affect the application launch.
• The startup command can be standardized and controlled by the IT team.
• Java parameters, memory settings, truststores, and logging can be explicitly configured.
• It is generally easier to reproduce and troubleshoot startup issues.
• It aligns better with current Java versions and Oracle’s modern Forms direction.

Disadvantages of FSAL

• The frmsal.jar launcher must be distributed to every workstation.
• The launcher version must match the Oracle Forms server version and patch level.
• IT must maintain the desktop shortcut or startup script.
• Java and the required certificates must be correctly deployed on each workstation.
• Updating or patching Forms may require redistributing frmsal.jar.
• SSO, single sign-off, JavaScript integration, and communication with web pages require careful validation.
• The initial workstation packaging may require more preparation than simply publishing a URL.

My experience with FSAL

FSAL generally requires more preparation during the initial rollout. The Java runtime, frmsal.jar, truststore, startup parameters, and shortcut must be packaged correctly.

Once that work is completed, the result is usually more predictable.

The application is no longer affected by browser behavior, JNLP file associations, or Java Web Start cache issues. When a startup problem occurs, the launch command and console output also provide a clearer troubleshooting path.

One important operational point is the management of frmsal.jar. It should not be treated as a generic launcher that can be reused forever. It is version-specific and must remain aligned with the Forms installation.

When should you choose FSAL?

FSAL is generally the better choice when:

• You are implementing a new Oracle Forms deployment.
• You are upgrading to a recent Oracle Forms release.
• You want to remove browser dependencies.
• You want to use a modern and centrally managed Java runtime.
• Workstations are managed using tools such as Microsoft Intune, SCCM, or another software distribution platform.
• You need predictable startup parameters and easier troubleshooting.
• Forms is primarily used as a business desktop application.

Direct comparison

My recommendation

For an existing, stable Java Web Start environment, I would not migrate to FSAL only for the sake of changing technology. The migration should provide a clear operational or security benefit.

For a new deployment or a major Oracle Forms upgrade, I would generally choose FSAL.

It removes the browser and Java Web Start dependencies, gives the IT team better control over the client runtime, and provides a more predictable operational model.

The final choice should nevertheless be validated against:

• The Oracle Forms version
• The certified client Java version
• The SSO implementation
• WebUtil and custom JAR usage
• JavaScript integration
• Proxy and TLS requirements
• The workstation deployment strategy

The key point is simple: Java Web Start is easier to expose through a URL, while FSAL is easier to control as a managed desktop application.

Oracle documentation

• Oracle Forms 12.2.1.4 – Client Configurations, Java Web Start and FSAL
• Oracle Forms 14.1.2 – Forms Standalone Launcher
• Oracle Forms 14.1.2 – Working with Oracle Forms

L’article Oracle Forms: Java Web Start or FSAL? 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.

At first, the issue looked like a Java or JDK problem. After a full investigation, it turned out to be different.

This blog explains the full story from beginning to end.

Introduction

Initial Objective

The initial goal was simple:

• apply the latest Oracle Fusion Middleware patch bundle
• restart the environment
• validate Forms and Reports services

The patch installation completed without any obvious errors, and patch inventory looked clean.

Issue after patching

Once the environment was started again, Oracle Reports was no longer stable.

Symptoms:

• Reports engine failed to start correctly
• Report execution was failing
• Oracle Reports processes were crashing shortly after startup
• The environment became unstable after patching

This immediately confirmed that the issue was introduced after the Oracle patching activity.

Investigation

The first checks focused on the usual areas:

• WebLogic status
• Reports server startup
• Reports engine diagnostic logs
• process status
• environment variables
• classpath and Java configuration

At this stage, the failure appeared during Reports engine initialization.

Crash Analysis

A deeper review showed JVM crash files (hs_err_pid) being generated.

The important finding was that the crash was not pointing to standard Java code.
It was occurring in the Oracle Reports native library:

• librw.so
• function around kguinit

This was an important clue because it suggested the problem was not a normal Java exception, but a failure in Oracle Reports native components.

JDK Validation

Because the issue started after patching, one possible explanation was a JDK problem.

Several validations were performed:

• Checked active Java paths
• Rolled back JDK version
• Retested with the previous JDK
• Compared behavior before and after JDK rollback

The same crash still happened even after JDK rollback.

That confirmed the issue was not caused by the JDK itself.

Rollback and Reproduction Test

To make sure the Oracle patch was really the trigger, I performed a controlled validation:

• Roll back Oracle patch
• Start environment
• Test Reports
• Reapply Oracle patch
• Retest Reports

Before patch: environment worked fine

After patch: issue was reproduced again.

This confirmed that the problem was patch-related and reproducible.

Real Root Cause Direction

After further analysis, it became clear that the problem was not just a startup configuration issue.

The patch had left the Oracle Reports native layer in an inconsistent state, and the environment needed a relink of Oracle FMW Reports and related shared libraries. I already had the case in the past with older versions (11 and 12), which normally has been solved since (related Oracle KB)!

That explained why:

• Patching succeeded
• Startup partially worked
• But Reports engine crashed in native code

Final Resolution

The final resolution was to relink Oracle FMW Reports.

First, the Reports environment was loaded:

cd $DOMAIN_HOME/reports/bin
. ./reports.sh

Then the Oracle Reports libraries and binaries were rebuilt:

cd $ORACLE_HOME/reports/lib
make -f ins_reports.mk install

This recreated and relinked key Reports components such as:

• librw.so
• librwu.so
• rwserver
• rwrun
• rwclient
• rwbuilder
• rwconverter
• rwcgi
• rwproxy
• rwrqv

After that, the Oracle client shared libraries were rebuilt as well:

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk client_sharedlib

This regenerated the Oracle client shared libraries and symbolic links required by the middleware binaries.

After the relink activity:

• Oracle Reports started correctly
• the engine no longer crashed
• report execution worked again
• the patched environment became stable

So the environment could remain patched and operational, without needing to stay rolled back.

Lessons Learned and key takeaway

This case was a good reminder that post-patching issues are not always caused by:

• Java
• Classpath
• Managed server configuration
• OS changes

Sometimes the real issue is lower-level and sits in:

• Oracle native binaries
• Shared libraries
• Incomplete or inconsistent linking after patching

So, please note that when Oracle Reports crashes inside librw.so after patching, and rollback proves the patch introduced the issue, a relink of Reports and Oracle client shared libraries should be considered as a serious corrective action.

Read more blogs

L’article Oracle Forms & Reports 14.1.2 Patching Issue est apparu en premier sur dbi Blog.

Introduction

Within WebLogic 14, out-of-the-box tools such as the Remote Console and WLST scripts provide some visibility, but they are limited when it comes to real-time metrics, historical analysis, or predictive monitoring.

This is where the Elastic Stack (Elasticsearch, Logstash, Beats, Elastic Agent, Kibana, and Elastic Machine Learning) delivers real value. By integrating WebLogic 14 logs, traces and metrics with Elastic Stack, you can build a unified platform that provides:

• Real-time observability of servers, threads, JDBC pools, and JVM health.
• Powerful visualization and analysis in Kibana.
• Predictive monitoring through anomaly detection and forecasting.

In this blog, we’ll walk through the integration of metrics step by step.

Step 1: Export WebLogic 14 Metrics

WebLogic does not natively expose metrics in formats suitable for Elastic or Prometheus. The solution is the WebLogic Monitoring Exporter, which translates JMX metrics into Prometheus-style output.

Download the exporter:

wget https://github.com/oracle/weblogic-monitoring-exporter/releases/download/v2.3.0/weblogic-monitoring-exporter.jar

Configure it (config.yaml):

domains:
  - name: mydomain
    url: t3://localhost:7001
    username: monitoruser
    password: XXXXXXXXXX
    metrics:
      - name: ServerHealth
      - name: ThreadPool
      - name: JDBCConnectionPool
      - name: JVMRuntime

Start the exporter:

java -jar weblogic-monitoring-exporter.jar --config=config.yaml

Verify metrics are exposed at:

http://localhost:8080/metrics

Step 2: Collect Metrics with Metricbeat

Elastic provides Metricbeat with a Prometheus module, making it easy to scrape WebLogic exporter metrics and send them to Elasticsearch.

Enable and configure the module:

metricbeat modules enable prometheus

prometheus.yml configuration:

- module: prometheus
  period: 10s
  hosts: ["http://localhost:8080"]
  metrics_path: /metrics

Start Metricbeat:

sudo metricbeat setup
sudo service metricbeat start

Now WebLogic metrics are flowing into Elasticsearch.

Step 3: Collect WebLogic Logs with Filebeat or Elastic Agent

Metrics give you system health, but logs provide context. To correlate performance issues with application errors, you should ingest WebLogic logs into Elasticsearch.

Option A: Using Filebeat

Install and configure Filebeat on the WebLogic server.

Example configuration (filebeat.yml):

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /u02/app/weblogic/domains/mydomain/servers/*/logs/*.log
    fields:
      application: weblogic
    multiline.pattern: '^\<'
    multiline.negate: true
    multiline.match: after

output.elasticsearch:
  hosts: ["http://localhost:9200"]

And start Filebeat.

Option B: Using Elastic Agent (Recommended)

Elastic Agent simplifies deployment by combining logs, metrics, and security data collection into a single agent managed centrally via Kibana Fleet.

Steps:

1. Enroll the agent from Kibana – Fleet.
2. Attach the System + Custom Log integration.
3. Configure the WebLogic log path.
4. Deploy the agent on your WebLogic server.

This approach reduces operational overhead and centralizes configuration.

Next steps & Conclusion

Next steps:

• Build Observability Dashboards in Kibana
• Add APM for Transaction-Level Visibility
• Enable Machine Learning for Predictive Monitoring
• Configure Alerts

While WebLogic 14 provides essential administrative tooling, it does not offer full observability capabilities out of the box.

By integrating it with the Elastic Stack, you gain:

• Real-time operational insight
• Deep log and metric correlation
• Predictive monitoring with machine learning
• Actionable alerting
• Transaction-level visibility

This approach scales from a single WebLogic instance to enterprise clusters and hybrid cloud deployments.

In short: you move from reactive troubleshooting to proactive performance management.

See my Elastic blogs.

L’article WebLogic 14 & Elastic Stack: From Metrics to Predictive Insights 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.