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.

Before we dive into commands and configurations, let’s anchor this in version history and explain an important staging step that many teams overlook.

WildFly version history

WildFly releases follow a rapid cadence, but some versions carry particular importance for migration:

Why Not Jump Directly from 26 to 38?

In theory you could try, but in practice, this is discouraged for several reasons:

1. Evolving Jakarta EE Support

WildFly 26 still contains remnants of older namespace patterns from the earlier Jakarta EE transition. WildFly 38 assumes:

• Full Jakarta EE 10 compliance
• Removal of deprecated subsystem elements

Staging through WildFly 36 means you pass through a version that:

• Consolidated many breaking changes
• Served as a stepping stone for configuration syntax modernization
• Was widely adopted and battle-tested by community users before WildFly 38

This reduces the “shock” of incompatible subsystems in one big jump.

2. Migration Tool Patching

The WildFly Migration Tool is better optimized when configurations change incrementally:

• From 26 to 36, the migration tool handles early syntax conversions
• From 36 to 38, it can focus on more recent modular and namespace adjustments

If you try to leap directly from 26 to 38, the migration tool may:

• Miss subtle differences
• Produce overly noisy reports
• Increase your manual remediation effort

Staging through 36 results in cleaner migration scripts, fewer manual manual fixes, and a more predictable process.

3. Security and Subsystem Consistency

Between 26 and 38, several subsystems saw significant reconfiguration:

• Elytron security policy changes
• Credential store formats
• Datasource definitions (Oracle and others became stricter)
• Logging and management interfaces

WildFly 36 introduced many of these changes incrementally so that:

• Administrators could adapt
• Tooling could reflect real-world environments before further evolution in WildFly 38

This made 36 a natural “landing zone” between the older 26 semantics and the newer 38 mechanics.

Migration Flow

The migration from WildFly 26 to WildFly 38 is intentionally performed in two controlled phases. This staged approach reduces risk, isolates problems earlier, and provides clear validation points before reaching the final production target.

Step 1 – Baseline: WildFly 26 (Current State)

The starting point is the existing WildFly 26 environment, typically running on Java 11 and hosting a stable, production-tested application.

At this stage:

• The platform is known and stable
• Configuration reflects historical decisions and legacy syntax
• Security, datasources, and deployments are tightly coupled to this version

No changes are made here except:

• Full backups
• Configuration review
• Inventory of customizations

WildFly 26 remains untouched and fully rollback-capable throughout the migration.

Step 2 – First Migration: WildFly 26 to WildFly 36

The first technical migration is performed using the WildFly migration tool, targeting WildFly 36.

This step focuses on:

• Converting legacy configuration syntax
• Removing deprecated or removed subsystems
• Preparing the configuration for newer Jakarta EE expectations

WildFly 36 acts as a transition platform:

• It supports Java 17
• It consolidates many breaking changes introduced after WildFly 26
• It allows configuration issues to be addressed incrementally rather than all at once

At this stage, the goal is not production readiness, but configuration correctness.

Step 3 – Staging and Validation on WildFly 36

Once the configuration is migrated, WildFly 36 is used as a staging environment for in-depth validation.

Key activities include:

• Running WildFly on Java 17
• Rebuilding or adjusting Elytron security components
• Recreating credential stores
• Validating datasource connectivity
• Starting the application and ensuring it runs
• Performing smoke tests and basic functional checks
• Allowing customer or application teams to execute targeted tests

When all tests pass:

• Configuration is frozen
• Known issues are documented
• The environment is considered stable enough to move forward

This step significantly reduces uncertainty before the final upgrade.

Step 4 – Second Migration: WildFly 36 to WildFly 38

With a validated configuration on WildFly 36, the second migration step is executed toward WildFly 38.

This phase:

• Uses the migration tool again
• Applies final syntax and subsystem adjustments
• Introduces stricter validation and enforcement present in WildFly 38

Because most major changes were already handled in the previous step, this migration is usually:

• Shorter
• Cleaner
• Easier to troubleshoot

WildFly 38 now represents the target platform, not just a test environment.

Step 5 – Final Validation on WildFly 38

Before production rollout, WildFly 38 undergoes final validation:

• Server startup and stability checks
• Security and datasource verification
• Application deployment validation
• Final smoke and regression tests

At this point, the platform should behave identically (or better) than WildFly 26, with the added benefits of:

• A modern Java runtime
• Up-to-date Jakarta EE support
• Improved security and maintainability

Step 6 – Production Rollout and Retirement of WildFly 26

Once validated:

• WildFly 38 is promoted to production
• Traffic is switched according to the customer’s deployment strategy
• WildFly 26 is retired in a controlled manner

Rollback remains trivial until decommissioning is complete, since:

• WildFly 26 was never modified
• All migrations were performed side-by-side

Summary

This staged migration approach ensures that:

• Configuration changes are isolated and understandable
• Security and infrastructure issues are discovered early
• Application teams have time to adapt and validate
• Production risk is minimized

By treating WildFly 36 as a stabilization checkpoint, the transition to WildFly 38 becomes predictable, controlled, and repeatable.

Don’t hesitate to reach out to discuss your WildFly or JBoss EAP migration project, we’ll be happy to help you move forward safely, efficiently, and with full transparency.

Related interesting blog: JBoss EAP vs Wildfly

L’article Migrating from WildFly 26 to WildFly 38 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.

With the release of WebLogic 14.1.2, Oracle has introduced significant updates that directly affect stability, security, and modernization. Below is an overview of what’s new and what it means for organizations planning to upgrade.

A Quick Stroll Through WebLogic History

What’s New in WebLogic 14

1. Modern Java Support

WebLogic 14.1.2 now officially supports JDK 17 and JDK 21. This provides access to performance improvements (e.g., G1GC, ZGC) and modern Java language features such as records, sealed classes, and switch expressions.

Impact for organizations:

• Applications gain performance and security improvements.
• Stricter Java module system may expose hidden dependencies.
• Legacy libraries or reflection-based solutions may fail.
• Outdated JDBC drivers and frameworks may require upgrading.

2. Strengthened Security Defaults

Security has been significantly improved in WebLogic 14:

• OpenID Connect support for integration with modern identity providers.
• TLS 1.0 and 1.1 removed; only strong cryptographic protocols are supported.
• Domain-specific demo certificates using PKCS12 keystores by default.

Impact for organizations:

• Easier integration with enterprise authentication and identity management.
• Legacy systems that depend on outdated SSL/TLS protocols will need upgrades.

3. Administration Console Evolution

The traditional WebLogic Admin Console has been retired and replaced with the Remote Console, a lightweight web application that communicates via REST APIs.

Advantages:

• Manage WebLogic securely from anywhere.
• Console can be upgraded independently from the server.

Considerations:

• Administrators must adapt to a new interface.
• Existing procedures, documentation, and training materials will require updates.

4. Migration and Refactoring Tools

Oracle introduced two new tools to assist with upgrades:

• Migration Analysis Tool (MAT): Scans applications and reports compatibility issues.
• OpenRewrite Recipes: Automates some application refactoring tasks.

Considerations:

• These tools provide useful guidance, but results often require expert interpretation.
• Automated refactoring may only cover part of the necessary work.

5. Clustering and Database Enhancements

Enhancements in high availability and database integration include:

• Health-based routing: Routes requests to the healthiest available node.
• Database client modules: Simplify integration in Kubernetes and containerized environments.
• Improved failover and multi-data center support: Reduce complexity in HA deployments.

Impact for organizations:

• More reliable clustering.
• Simplified operations in cloud and hybrid environments.
• Better resilience in multi-DC architectures.

Should You Upgrade?

Short answer: yes. Long answer: yes, but carefully.

Sticking with 12c in 2025 is like still using Internet Explorer – technically possible, but also technically embarrassing. At some point, Oracle’s support matrix will drop you, and then you’re one zero-day away from chaos.

In another world, continuing to run WebLogic 12c in 2025 is increasingly difficult to justify:

• Security vulnerabilities accumulate as older versions leave support.
• Integration with modern Java, Kubernetes, and identity providers becomes more challenging.
• Oracle’s support matrix is moving forward, and legacy environments are becoming costly liabilities.

Final Thoughts

WebLogic 14 is not just an incremental update. It modernizes the platform with stronger security, cloud-native capabilities, and support for the latest Java standards. At the same time, it introduces changes that require careful planning to avoid disruption.

This is where experienced guidance is valuable. With years of WebLogic consulting experience, I support organizations by:

• Auditing WebLogic installation for compatibility issues before migration.
• Planning and executing upgrades with minimal downtime.
• Configuring new security features and administration tools correctly.
• Coaching development and operations teams to adapt to the changes.

If your organization is considering upgrading to WebLogic 14, let’s discuss how to make the transition smooth, secure, and future-proof.

Happy to share,

David

Have a look to all my blogs

L’article WebLogic 14: What’s New and Why It Matters est apparu en premier sur dbi Blog.

Introduction and Symptoms

An important step in the installation process is the Oracle Fusion Middleware Metadata repository creation using the RCU (Repository Creation Utility) which creates the necessary schemas for the components.

But when running the Repository Creation Utility (RCU) to load schemas on Oracle Database, schema creation fails with the below errors:

In fact, the problem is seen as RCU tries to set up VPD stripes. In another world, RCU relies on fine-grained access control (FGAC) to manage schema creation and access within the Oracle database.

The ORA-00439 error “feature not enabled: Fine-grained access control” in Oracle RCU (Repository Creation Utility) indicates that the database being used for RCU schema creation does not have the fine-grained access control feature enabled. This feature is only part of the Enterprise Edition of Oracle Database and is not available in Standard Edition!

Let’s check

So, no way to do it with Standard Edition? No worries, there is a solution

Solution

Oracle here is a patch to workaround this issue, so the steps will be:

• Download the patch
• Apply the patch
• Run the RCU to load the schemas
• Continue with Domain configuration

Download the patch

Go to Patch 37506854 and download it, then move it to your working folder on the server.

Apply the patch

Nothing really special here, apply the patch as any patch

Unzip the patch downloaded, go inside the folder 37506854, and apply the patch:

[oracle@fmwserver working]$ cd 37506854
[oracle@fmwserver 37506854]$ opatch apply
Oracle Interim Patch Installer version 13.9.4.2.17
Copyright (c) 2025, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/midw
Central Inventory : /u01/app/oracle/oraInventory
   from           : /u01/app/oracle/product/midw//oraInst.loc
OPatch version    : 13.9.4.2.17
OUI version       : 13.9.4.0.0
Log file location : /u01/app/oracle/product/midw/cfgtoollogs/opatch/opatch2025-07-10_11-22-38AM_1.log


OPatch detects the Middleware Home as "/u01/app/oracle/product/midw"

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   37506854

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/midw')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '37506854' to OH '/u01/app/oracle/product/midw'

Patching component oracle.rcu.mds, 14.1.2.0.0...

Patching component oracle.rcu.mds, 14.1.2.0.0...
Patch 37506854 successfully applied.
Log file location: /u01/app/oracle/product/midw/cfgtoollogs/opatch/opatch2025-07-10_11-22-38AM_1.log

OPatch succeeded.

Retry the failed step

Now, the RCU should work fine and the domain creation could be done without issue.

Have a look on all FMW blogs, more blogs to come about FMW 14 to highlight new features!

If you have any questions don’t hesitate, please ask

Happy to share,

David

L’article Oracle FMW 14 Installation – ORA-00439: feature not enabled: Fine-grained access control est apparu en premier sur dbi Blog.

In this blog, I will share with you how to do the installation of this solution step by step. Let’s remember the architecture.

Deploy kubernetes Plug-in

Firstly, download the Kubernetes Plugin, download the version 2.0.00 from the Kubernetes plug-in download page in the Electronic Product Distribution site.

Once downloaded, publish the plug-in by putting the zip file in the following location:

$HOME_CTM/ctm_em/AUTO_DEPLOY

Generate an API Token

Basically, the API Token will be used later in the next step. In fact, we need to set up access to Control-M to register the Control-M/Agents, for sure, this step should be done by a Control-M Administrator.

I assume that you know what is an API Token, and how to generate it, below are the steps quickly.

To generate the API Token, go to the Control-M UI -> Configuration, from the drop-down list, select API Tokens.

The API Token tab appears, click Add Token.

To generate the API Token, fill the following:

• The Token Name field.
• The Roles field, remove or select the roles that you want to associate with the API Token (by default all roles are selected, which is not recommended).
• Expiration Date, select Indefinitely from the drop-down list.

Click on Generate button.

Prepare the Control-M Agent deployment

I recommend to deploy the agent using the Helm shared by BMC! It is easy to configure and to maintain in a Kubernetes cluster.

First of all, add a repository named controlm to contain the helm charts of the Control-M/Agent that is obtained from the Control-M Repository by running the following:

helm repo add controlm https://controlm-charts.s3.us-west-2.amazonaws.com/

Then, ensure that the Control-M repository is listed as one of your repositories by running the following command line:

helm repo list

You can also list the charts within the new controlm repo by running the following command:

helm search repo controlm

Create the namespace, by executing the following:

kubectl create namespace ctmagt

Control-M Agent deployment

To deploy the Control-M Agent you should execute the Helm Install inside your kubernetes cluster:

helm install ctm-dbi controlm/controlm-agent --version 9.21.200 \
--set server.name=dbitest --set server.host=dbitest --set server.port=7005 --set server.ip=XX.XX.XX.XX \
--set api.endpoint=https://dbitest.x.com:8446/automation-api \
--set api.token=b2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX== \
--set pvc.storageClass=dbistorage

Adapt the command line to your environment!

Check the pod status on the namespace (ctmagt) just created, once the agents pods are ready, check if they appear in Control-M -> Configuration.

By default, two pods should be created, two agents deployed. Sometimes agents are not available directly, don’t hesitate to disable and enable them.

Conclusion

Finally, we have two Control-M agents deployed on Kubernetes.

In the next blog we will see how to create the connection profile, and how to create Control-M jobs to execute Kubernetes jobs.

L’article Control-M for Kubernetes – Installation 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.