WLS 9.0 Management API – Part 2

In my last blog we discussed what we had to manage WLS prior to 9.0. There are many changes in 9.0, few important changes are, Management API based on JMX 1.2, adopted to JSR 160 and new functionality aligned MBeanServers. JSR 160 defines the remotable API for JMX, making it possible for clients to connect to a remote JMX MBeanServer without any proprietary classes in the classpath. By the way, Sun now bundles JMX 1.2 with JDK 1.5 (i.e. JMX classes are in the boot classpath). Since we have a standard way to remotely connect to a JMX Agent, BEA deprecated its Remotable extensions MBeanHome and RemoteMBeanServer. BEA also deprecated the type-safe stubs that MBeanHome used to return when you lookup an MBean and now recommends using straight JMX or WLST. With 9.0 the config.xml is schema based which lets users to use tools like XMLSpy to edit the configuration offline. Prior to 9.0, we had only one MBeanServer that hosted all MBeans (Configuration, Runtime & Custom). In 9.0 WLS has four MBean servers, each of which provides access to different MBeans depending on their functionality. The Edit MBean Server provides access to the editable configuration MBeans, the Domain Runtime MBean Server provides federated access to all Runtime MBeans and read-only configuration MBeans in the domain, the Runtime MBean Server provides access only to the Runtime and read-only configuration MBeans and the Compatibility MBeanServer provides access to all deprecated MBeans.
Let us make a one-one comparison between WLS prior to 9.0 and 9.0.

WLS Management from 6.0 to 8.1 WLS Management from 9.0 & above
Proprietary Remotable APIs to access MBeanServer Standards based, JSR 160. Deprecated MBeanHome & RemoteMBeanServer
One MBeanServer, hosted all MBeans 4 MBeanServers, each MBS hosts MBeans depending on functionality
Non schema based config.xml Schema based config.xml
Many broken links in MBean hierarchy All MBeans completely Linked, making the hierarchy traversable
MBeanHome – Factory for creation/deletion of all MBeans Each parent MBean serves as a Factory to create/delete its Child MBeans
Configuration change mechanism is atomic Introduction of transaction semantics to configuration change
No control over configuration changes and often unpredictable Need a lock on configuration to make a change, more control (can undo changes, stop edits etc)
AdminMBeanHome provided the federated view of the Domain DomainRuntime MBeanServer provides the federated view of the Domain
CommandLine administration via weblogic.Admin Deprecated weblogic.Admin, introduced WLST
WebLogic Domain Name in MBean’s ObjectName, ex: mydomain:Name=myserver,Type=Server Changed to com.bea, ex: com.bea:Name=myserver,Type=Server
config.xml represented all WLS configuration {domain_dir}/config directory represents WLS configuration i.e config is spread across multiple xml files (JMS, JDBC & WLDF config in different files)
None Service MBeans to get to the root MBeans


Now here’s what you will do in WLS 9.0 to get to the ServerMBean.
// All JMX imports that you need
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

// Assuming you know these
String protocol = “t3″; // can be t3, http, iiop
String hostname = “localhost”;
int port = 7001;
String uri = “/jndi/” +”weblogic.management.mbeanservers.runtime”;
// Create a JMX Service URL
JMXServiceURL serviceURL = new JMXServiceURL(protocol, hostname, port, uri);
// Setup connection properties
Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, “weblogic.management.remote”);
// this one points to a BEA class
// Create a connection to the RuntimeMBeanServer
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, h);
// Get the RuntimeMBeanServer
MBeanServerConnection connection = connector.getMBeanServerConnection();
// Get the Runtime Service MBean
ObjectName service = new ObjectName(“weblogic:Name=RuntimeService”);
// Get the Domain MBean
ObjectName domain = (ObjectName) connection.getAttribute(service,”DomainConfiguration”);
// Get the ServerMBean
ObjectName server = (ObjectName) connection.getAttribute(domain,”ServerConfiguration”);
String name = (String) connection.getAttribute(server, “Name”);
System.out.println(“Server’s name “+name);

Alternatively you can write a simple WLST script in far less lines to achieve the same, but ofcourse you will need weblogic classes in your classpath. Here’s how your script will look like.
# assuming you know the username, password and url
connect(username, password, url)
svr = cmo.lookupServer(‘myserver’)
print svr.getName()

This is an overview of Management API changes in 9.0. In my BEAWorld session on WLST I am going to briefly discuss these changes. For more information please check out BEA Edocs.

_uacct = “UA-2684269-2″;
urchinTracker();

One Response to “WLS 9.0 Management API – Part 2”

  1. Ramanna says:

    Hi Satya,
    Is there a way we can set a property to multiple servers in the same edit session? I am getting an exception if I use the below script

    def setPath():
    connect(“weblogic”,”web_logic”,”localhost:7001″)
    servers = adminHome.getMBeansByType(‘Server’)
    edit()
    startEdit()
    for name in servers:
    print ‘calling edit and startedit’
    str=name.getName()
    print ‘=====servername =========’+str
    prefix = str[0:4]
    ServerStartMBean=name.getServerStart()
    ServerStartMBean.setClassPath(“lib/test.jar:lib/test1.jar:lib/test2.jar”)
    save()
    activate(block=”true”)

    if __name__== “main”:
    print ‘calling setpath method ‘
    setPath()