The WebLogic Remote Console can connect directly to a WebLogic Administration Server to view and edit its domain, much like the WebLogic Server Administration Console, though there are some differences.
You can save the connection details for multiple WebLogic Administration Servers, making it easy to switch between domains with a click.
Start the WebLogic Administration Server.
Open the Providers drawer and beside the project name, click ⋮. Select Add Admin Server Connection Provider.
Enter a name for the Administration Server connection. This is the name that will appear in the Project list of providers so you can identify which provider you’re working on.
Enter a username and password for a user account with editing privileges in the selected Administration Server. As with the Administration Console, your management capabilities will be limited depending on the level of access granted to your user account. See Understand access discrepancies for more information. You can choose to have multiple connections to the same Administration Server with different users.
Enter the URL for the Administration Server.
Note: Make sure that the management/*
endpoint of your administration server is accessible by the WebLogic Remote Console. If your administration server’s endpoints are behind a load balancer or otherwise externally unavailable, you will need to expose that endpoint manually.
Optional:
Click OK to connect the WebLogic Remote Console to the WebLogic Administration Server.
The WebLogic Remote Console is now connected to a WebLogic Administration Server. You can make changes to the domain as desired.
You can use the WebLogic Remote Console to manage a WebLogic Server domain running on Kubernetes. For details about how to set up access to WebLogic Server domains running on Kubernetes, see Use the Remote Console in the WebLogic Kubernetes Operator User Guide.
Editing a domain in the WebLogic Remote Console is similar in process to the Administration Console. When you start editing a domain, a configuration lock is created that blocks other users from making simultaneous changes. Once you’re satisfied with your changes, you can activate these changes and perpetuate them to the Administration and Management Servers.
Certain areas and actions in the WebLogic Remote Console are hidden from non-administrators. For example, users with the Operator role cannot see the Edit Tree at all. For more information on what each user role can (or cannot) access, see Understand Access Discrepancies.
You can restore fields to their default value. Right-click on a field and click Restore to default.
The Shopping Cart (equivalent to the Change List in the WebLogic Server Administration Console) holds all the pending changes for the current session in the WebLogic Remote Console. In the shopping cart, you can see if any changes are pending, commit those changes or discard them entirely.
If you installed the console extension, console-rest-ext-6.0.war
, then you can also see the specific changes you’ve made and the status of the lock in the Change Manager.
Open the Shopping Cart menu and click View Changes to see your pending changes.
Some changes can be activated immediately (dynamic) while other changes require a server restart to activate (non-dynamic). When you need to activate non-dynamic changes, navigate to the Environment > Servers node in the Monitoring perspective to see which servers need a restart.
If you need to undo a change, you must discard all Shopping Cart contents or manually revert the change in the Edit Tree perspective.
The configuration change lock does not prevent you from making conflicting configuration edits using the same administrator user account. For example, if you obtain a configuration change lock in the WebLogic Remote Console, and then use the Administration Console or WebLogic Scripting Tool (WLST) with the same user account, you will access the same edit session that you opened in the WebLogic Remote Console and you will not be blocked from making changes with the other tools.
We recommend against making changes using multiple tools because when one of the sessions activates their changes, it releases the lock and the other session will not be able to save or activate their changes.
It’s easy to view the details of a WebLogic Server Connection.
A list of connection details will appear, including:
This will only delete the WebLogic Remote Console access to the WebLogic Administration Server. The domain itself will be unaffected.
The WebLogic Remote Console provides control operations for the Administration Server in the Monitoring perspective.
Server state indicates the specific condition of a server in the life cycle management.
The WebLogic Remote Console includes simplified wizards for deploying applications and creating JDBC system resources.
In most other cases, when you create a new MBean on a page, you are prompted to fill in a few key properties, such as Name, then click Create. Unlike the WebLogic Server Administration Console, the WebLogic Remote Console does not guide you through configuring other properties that you typically need to complete the configuration. Instead, it displays the new bean’s pages where you can click through the tabs to finish configuring the bean.
When you configure a bean property that references another bean, you must first create the other bean. For example, if you want to assign Server1 to Cluster1, you need to create Cluster1 first, unlike in the WebLogic Server Administration Console where you can choose to create Cluster1 during server creation.
You can use the WebLogic Remote Console to manage the deployment process for applications to WebLogic Server.
For more information on the general process for application deployment, see Deploying Applications to Oracle WebLogic Server.
When you install an application, you make its physical file or directory known to WebLogic Server. An application can be installed as an archived EAR file or as an exploded directory.
Your new application appears under the App Deployment node. You can make additional changes to the application on this page.
You must start an application before it can process client requests.
You need to start an application to make it available to WebLogic Server clients.
When you start an application, you can make it immediately available to clients, or you can start it in Administration Mode to first ensure that it is working as you expect. Starting in Administration Mode allows you to perform final (“sanity”) checking of the distributed application directly in the production environment without disrupting clients.
When you stop an application, you can choose whether no clients can use it, or stop it in Administration Mode so that only administrative tasks can be performed.
Stopping an application does not remove its source files from the server; you can later redeploy a stopped application to make it available to WebLogic Server clients again.
You can use a deployment plan to specify deployment property values for an application. A deployment plan is an optional document that works with or overrides your application’s deployment descriptors to configure an application for deployment to a specific WebLogic Server environment. Deployment plans are written in XML.
For more information, see Understanding WebLogic Server Deployment Plans in Deploying Applications to Oracle WebLogic Server.
plan.xml
. It’s recommended that you store a deployment plan for a single application in its own plan/
subdirectory of the application’s root directory.You can update a deployment plan with new deployment instructions for an application.
For more information, see Manually Customizing the Deployment Plan in Deploying Applications to Oracle WebLogic Server.
If your changes include non-dynamic changes, you must redeploy the application to propagate the changes from the deployment plan to the application.
For more information, see Overview of Redeployment Strategies in Deploying Applications to Oracle WebLogic Server.
To redeploy an application with an updated deployment plan.