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, firewall, 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.
The Administration Server provider is split into multiple perspectives, each of which focuses on a different management area for a WebLogic domain:
While the Edit Tree and the Configuration Tree perspectives look similar, they are generated from two separate collections of configuration MBeans, which results in important and distinct nuances between the two perspectives:
Changes made in the Edit Tree perspective do not appear in the Configuration Tree perspective until you commit them, or for non-dynamic changes, until you restart the server.
Certain dynamically computed domain contents do not appear in the Edit Tree. For example,
For more information on the differences between editable Configuration MBeans and read-only Configuration MBeans, see Managing Configuration Changes in Understanding Domain Configuration for Oracle WebLogic Server.
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-2.4.11.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.
After you deploy an application, you may want to confirm that it was deployed successfully.
In the Monitoring Tree, navigate to Environment > Servers > myServer > Deployments > Application Runtimes > myApp > Component Runtimes > myServer/myApp > Servlets.
Construct a URL using the target server address plus the ContextPath
and Name
values from the Servlets table. For example, for an application deployed on the Administration Server, a test URL might look like http://adminserver:7001/myapp/welcome
.
Note: Remember to consider any changes you made to network channels that may affect the application deployment. For example, the application may be on a different port.
Enter the URL into your browser. If the page loads correctly, then your application was deployed successfully.
After you deploy an application, you can configure additional settings to meet the needs of your environment.
If you haven’t already, create a deployment plan for the application. You can view the default configuration settings but they are read-only until you create a deployment plan. For more information, see Deployment Plans.
Note: You cannot create a deployment plan for applications that were auto-deployed.
In the Monitoring Tree, navigate to Deployments > Application Management and select your application.
Click Create Plan.
In the Plan Path field, enter a file path for the new deployment plan. You should create the new deployment plan for a single application within a plan/
subdirectory of the application’s root directory. Deployment plans must be in XML format and should be called plan.xml
.
Click Done. WebLogic Server will create a basic deployment plan.
Note: You can see the deployment plan for an application under Deployments > Application Management > myApplication > Deployment Plan (Advanced).
Go to Deployments > Application Management > myApplication > Configuration. Explore the Configuration node and its children to see the available deployment configuration options.
Note: The contents of the Configuration node and its children differ based on application type. For example, web applications include settings for container descriptors while resource adapters include settings for outbound connection pools.
Click Save as you make changes. Any changes that you make to the Configuration node and its children are automatically reflected in the deployment plan.
Update and possibly redeploy your application to apply your changes. See Update or redeploy an application for instructions.
If your changes are dynamic, then you only need to update the deployment plan. However, 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 update or redeploy an application with an updated deployment settings.
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.
Note: You cannot create a deployment plan for applications that were auto-deployed.
Generally, if you need to modify the deployment settings of an application, you should use the Configuration node (as described in Configure Deployment), instead of manually editing the deployment plan.
plan/
subdirectory of the application’s root directory. Deployment plans must be in XML format and should be called plan.xml
.You can manually edit a deployment plan to update it with new deployment instructions for an application.
For more information, see Manually Customizing the Deployment Plan in Deploying Applications to Oracle WebLogic Server.