Posted on

Managing Oracle Weblogic with WLST


Running WLST in online mode

Online WLST provides simplified access to Managed Beans (MBeans) which are Java objects that provide a management interface for an underlying resource that you can manage through JMX. Since WLST is a JMX client, all the tasks you can do using WLST online, can also be done programmatically using JMX. Start by connecting to your running Administration server:

wls:/(offline)> connect(‘username’,’password’, ‘t3://localhost:7001’)

Connecting to weblogic server instance running at t3://localhost:7001 as username weblogic …

Successfully connected to Admin Server ‘myserver’ that belongs to domain ‘mydomain’.


You can also use WLST to connect to Managed Servers, but you cannot modify configuration data from Managed Servers; because this should only be done by the Administration Server which is solely responsible for maintaining, updating, and storing the configuration data.

Once you are connected to your WebLogic server instance, you can start navigating and querying MBeans. There are two main paths which can be traversed once you are connected to a WebLogic server instance: Configuration MBeans and RuntimeMBeans.

Entering Configuration MBeans

Configuration MBeans are used to explore the basic server configuration. You can navigate to configuration MBeans by using serverConfig or domainConfig (the latter one if you are connecting through the administration server):

wls:/base_domain/serverConfig> serverConfig()

Location changed to serverConfig tree.

With ls() you can have a look though this MBean structure:

wls:/mydomain/serverConfig> ls()

dr–   AppDeployments

dr–   BridgeDestinations

dr–   Clusters

dr–   DeploymentConfiguration

dr–   Deployments

dr–   EmbeddedLDAP

-r–   AdminServerName                              myserver

-r–   AdministrationMBeanAuditingEnabled           false

-r–   AdministrationPort                           9002

-r–   AdministrationPortEnabled                    false

-r–   AdministrationProtocol                       t3s

-r–   ArchiveConfigurationCount                    5

Entering Runtime MBeans

Similar to the configuration information, WebLogic Server Runtime MBeans are arranged in a hierarchical data structure. When connected to an Administration Server, you can access the Runtime MBean hierarchy by entering the serverRuntime or the domainRuntime command.

The serverRuntime command places WLST at the root of the server runtime management objects – ServerRuntimeMBean;

The domainRuntime command places WLST at the root of the domain-wide runtime management objects – DomainRuntimeMBean. (The domain runtime MBean hierarchy exists on the Administration Server only).

Here’s for example how you can check health state information about one application deployed on WebLogic Server:

wls:/base_domain/domainRuntime> serverRuntime()

Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.

And now let’s issue a directory listing:

wls:/base_domain/serverRuntime> ls()

dr–   ApplicationRuntimes

dr–   AsyncReplicationRuntime

dr–   ClusterRuntime

dr–   ConnectorServiceRuntime

. . . . .

-r–   MiddlewareHome                               C:\Weblogic

-r–   Name                                         AdminServer

-r–   OpenSocketsCurrentCount                      2

-r–   OracleHome                                   C:\Weblogic

-r–   RestartRequired                              false

-r–   SSLListenAddress                   

-r–   SSLListenPort                                7002

-r–   SSLListenPortEnabled                         true

-r–   ServerClasspath                              C:\Weblogic\wlserver/endorse

. . . .

wls:/base_domain/serverRuntime> cd (‘ApplicationRuntimes’);

wls:/base_domain/serverRuntime/ApplicationRuntimes> ls()

dr–   SystemModule-0

dr–   WLSDemo

. . . .

wls:/base_domain/serverRuntime/ApplicationRuntimes> cd (‘WLSDemo’);

wls:/base_domain/serverRuntime/ApplicationRuntimes/WLSDemo> ls()

. . . .


-r–   ActiveVersionState                           2

-r–   ApplicationName                              WLSDemo

-r–   HealthState                                  Component:null,State:HEALTH_


. . . .

A special variable, named cmo, is set as a pointer to the bean instance you are navigate into. You can use this variable to perform any get, set, or invoke a method on the current bean instance.

wls:/base_domain/serverConfig> cmo


wls:/base_domain/serverConfig> cd (‘Servers’)

wls:/base_domain/serverConfig/Servers> ls()

dr–   AdminServer

dr–   WLSNode1

dr–   WLSNode2

. . . . .

wls:/base_domain/serverConfig/Servers> cd (‘WLSNode1’);

wls:/base_domain/serverConfig/Servers/WLSNode1> cmo


Editing MBeans

Inspecting the values of MBeans is just half of your administrator activities. Within the Administration Server, there is a set of configuration MBeans in a single, editable hierarchy that contains an editable copy of all configuration MBeans in the domain and it is used only as part of the change management process.


The change management process is a controlled procedure for distributing configuration changes in a domain; a change process that loosely resembles a database transaction.

You start the editing process by obtaining a lock on the editable configuration hierarchy to prevent other people from making changes. When you finish making changes, you save and distribute them to all server instances in the domain. When you distribute changes, each server determines whether it can accept the change. If all servers are able to accept the change, they update their working hierarchy of configuration MBeans and the change is completed.

Here’s for example, how you can modify the ‘FileCount’ logging attribute

wls:/base_domain/serverConfig/Servers/AdminServer/Log/AdminServer> edit()

wls:/base_domain/edit !> startEdit()

wls:/base_domain/edit !> cd(‘Servers/AdminServer/Log/AdminServer’)

wls:/base_domain/edit/Servers/AdminServer/Log/AdminServer !> set(‘FileCount’, ‘8


wls:/base_domain/edit/Servers/AdminServer/Log/AdminServer !> save()

wls:/base_domain/edit/Servers/AdminServer/Log/AdminServer !> activate()

Activating all your changes may take a while; however the edit lock associated with this edit session is released once the activation is completed.

Notice the usage of thestartEdit command that initiates the editing process. Changes will not be committed to the repository until you enter the save command. The activate command initiates the distribution of the changes and releases the lock; finally notice that you can make additional changes, without re-entering the startEdit command, or undo changes you have made by entering the undo command.