Pages

Monday, February 2, 2026

R.I.P. "WebLogic Blue Console": Welcoming the Next Generation of Open-Source Remote Management

In December 2024, Oracle reached a major milestone with the release of Fusion Middleware (FMW) 14.1.2. This release brings critical updates to the entire stack, including WebLogic Server, Coherence, Oracle Identity & Access Management, SOA Suite, BPM, Data Integrator (ODI), WebCenter, and Forms & Reports.

Since WebLogic serves as the foundational runtime for most of these products, its evolution is central to the modern middleware ecosystem. Perhaps the most significant change in this release is the decommissioning of the traditional “Blue” WebLogic Admin Console in favor of the new, open-source WebLogic Remote Console (WRC).

Why the Change?

The classic WebLogic console served us well for over 15 years, but its legacy framework became difficult to modernize and support in cloud-native environments. The new WebLogic Remote Console is a complete reimagining of the management interface. Built on the Electron.js framework, it is lightweight, fast, and modern.

As an open-source project, the source code is publicly available on GitHub, allowing the community to fork the repository, contribute improvements, and stay updated with frequent releases.

Key Benefits of the WebLogic Remote Console (WRC)

The transition from the “Blue Console” to WRC isn’t just a UI facelift; it offers several architectural advantages:

  • Multi-Domain Management: Unlike the old console (one domain per browser tab), WRC allows you to connect to and manage multiple WebLogic domains—running anywhere—from a single interface [04:13].
  • Performance & Flexibility: WRC operates as a standalone client (Desktop or Browser-based) that communicates with servers via REST APIs [05:03]. This makes it significantly faster and more responsive than the old server-side rendered console [14:20].
  • Lightweight Footprint: By removing the console files from the server side, the WebLogic binary size is reduced by approximately 500 MB, which is a massive win for Docker and Kubernetes deployments [04:36].
  • Modern Troubleshooting: Features like direct Thread Dumps and integrated log viewing are built into the UI, eliminating the need to jump into the server command line for basic diagnostics [09:34].
  • Improved Security: Because the console doesn’t need to run on the production server, you reduce the attack surface of your middleware environment.

Getting Started

Whether you prefer a Desktop application for your Mac/Windows/Linux machine or a centralized browser-based deployment, WRC gives you the flexibility to choose. The project is well-documented with a comprehensive FAQ to help you navigate the transition.

Watch the Webinar

I recently hosted a webinar that dives deep into the features of the WebLogic Remote Console, including a live demo of application deployment and monitoring.

If you are planning an upgrade to 14.1.2 (14c), adopting this console is a must. Watch this 17-minute recording to get up to speed:

Manage WebLogic Anywhere: The Modern Remote Console

(In this video, I cover everything from connecting to multiple domains [07:09] to performing real-time application deployments [12:44] and monitoring JVM health [09:26].)

Manage WebLogic Anywhere: The Modern Remote Console**

Monday, September 22, 2025

Connecting JDeveloper to an Oracle Autonomous Database SOA MDS Repository: A Troubleshooting Guide

Recently, while assisting a customer with a high-priority issue, I encountered a connection problem in my personal Oracle SOA Suite environment. As part of a replication exercise, I needed to connect my JDeveloper instance to an Oracle SOA Metadata Services (MDS) repository, which is a critical component for managing shared artifacts in a SOA environment. The unexpected error I received had no clear solution on internal or Oracle support forums, so I’m sharing the solution here to help fellow SOA developers.

My environment for this exercise was Oracle SOA Suite 12.2.1.4, backed by an Oracle Autonomous Database (ATP) 19c.

 

The Problem:

I was unable to establish an MDS repository connection from JDeveloper, which is a prerequisite for deploying shared SOA artifacts like x-ref, XSD, XSLT, and WSDL files. The specific error message I received was:

 

  • Error reading db partition for connection name soadb1-apacanzset03
  • Reason : MDS-00003: error connecting to the database
  • Java.sql.SQLRecoverableException: IO Error: Unknown host specified]

 

The Solution:

The root cause of this error lies in the secure nature of the Oracle Autonomous Database. Unlike standard databases, ATP requires a Wallet file for secure connections. The Wallet contains crucial files like tnsnames.ora, truststore.jks, and keystore.jks, which are necessary for JDBC connections.

 

Steps to Configure the Connection:

  1. Download the ATP Wallet: First, download the Wallet.zip file from your ATP console.
  2. Unzip the Wallet: Extract the contents of the zip file to a secure, easily accessible location.
  3. Create new folders:  create folder structure “network>>admin” folder inside wallet folder and move tnsname.ora file into this location
  4. Configure JDeveloper: Next, you must update the jdev.conf file, located at $Middleware_HOME/jdeveloper/jdev/bin/, by adding the following Java options. These options point JDeveloper to the security files within your unzipped Wallet.
    • AddVMOption -Doracle.net.tns_admin=<Path to unzipped Wallet folder>
    • AddVMOption -Djavax.net.ssl.trustStore=<Path to truststore.jks file>
    • AddVMOption -Djavax.net.ssl.trustStorePassword=<your wallet password>
    • AddVMOption -Djavax.net.ssl.keyStore=<Path to keystore.jks file>
    • AddVMOption -Djavax.net.ssl.keyStorePassword=<your wallet password>
    • AddVMOption -Doracle.net.ssl_server_dn_match=true
  • Restart JDeveloper: Restart JDeveloper to apply the new configuration settings.
  • Create a Database Connection: Navigate to the Database navigator, create a new connection using the <soadbname_MDS> user, and test the connection.
  • Create an MDS Connection: Finally, go to Windows > Resources > New SOA MDS Connection. Specify a name, select "DB based MDS," choose the database connection you just created, and specify "soa-infra" as the partition. Test the connection, and it should now be successful.
This process ensures that JDeveloper can securely authenticate and connect to your ATP-based MDS repository, allowing you to manage and deploy your design time MDS artefacts to Server side MDS artifacts.

Friday, May 24, 2024

Fatal error, will return 1. Java output Line=: 1 FATAL: Error in discovery : Exception=java.lang.RuntimeException: java.lang.RuntimeException: javax.naming.CommunicationException [Login failed for an unknown reason: HTTP/1.1 404 Not Found]

Background

We were trying to Add Fusion Middleware SOA/Weblogic target inside Oracle Enterprise Cloud control 13c. Both components been deployed in Oracle Cloud Infrastructure using Market Place Image.

OEM Product Version: 13.5.0.19

SOA Suite 12.2.1.4

 As stated in below screen shot- 

 

but were hitting this Error message - 

Connecting with soamp-soa-0.spokedsoa.spokedvcn.oraclevcn.com:7001 weblogic ...... service:jmx:t3://soamp-sxxa-x.xxxxxsoa.sxxxxdxx.xxxxvxx.com:7001/jndi/weblogic.management.mbeanservers.domainruntime
sdk.discovery.discover.WeblogicDiscovery.discover debugging enabled.
sdk.discovery.discover.DiscoveryThread.setDiscoveryInputBeanBase enabling debugging
sdk.discovery.discover.DiscoveryThread.run In
sdk.discovery.discover.DiscoveryThread.discover In
sdk.discovery.discover.DiscoveryThread.discover In
sdk.discovery.discover.DiscoveryThread.run Out
sdk.discovery.discover.WeblogicDiscovery.discover Sleep Count = 1
sdk.discovery.discover.WeblogicDiscovery.discover Thread is not alive
sdk.discovery.discover.WeblogicDiscovery.discover getDiscoveredTargets
FATAL: Error in discovery : Exception=java.lang.RuntimeException: java.lang.RuntimeException: javax.naming.CommunicationException [Login failed for an unknown reason: HTTP/1.1 404 Not Found]
java.lang.Exception: java.lang.RuntimeException: java.lang.RuntimeException: javax.naming.CommunicationException [Login failed for an unknown reason: HTTP/1.1 404 Not Found]

We spent significant time to troubleshoot that error. MOS 1458357.1 helped up to some extent by enabling debug mode for emagent_perl.trc log file, also advising oracle_wls.pl scipt file which gets used to discover the target but still problem was not resolved. 

Until i found another blog talking about checking JMX service running or not within Weblogic Server. 

In order to search about JMX Server status, you need to check either your <domain>.log or AdminServer.log. Search this BEA code inside your log - 

cat soamp_adminserver.out | grep BEA-149512


In this we noticed that JMX Server actually using 9071 port vs we were using 7001 default WLS http port. 

The moment we changed from 7001 to 9071 port OEM was able to discover SOA Domain and pull out all target details. 

This document also state all default port of WLS and its purpose - https://docs.oracle.com/en/cloud/paas/weblogic-cloud/user/default-ports.html 

When I was searching for above erorr message couldn't find any useful blog detailing exact error. Hence, thought to publish this quick solution blog post. 

I hope that help. 

Happy blogging :)