Ghattu's Technology Blog

I worked many years at BEA mostly developing tools and applications that ease the management and administration of WebLogic Server. May be that is the reason why I get very excited when I come across something that is geared towards making developers & admin’s life easier. In that context I should mention Geronimo Administration console. I have been using Geronimo 1.1 for a while to build a few simple applications usually WebApps, mostly non-critical and deparmental. (No, I haven’t abandoned WebLogic .. . Geronimo Administrative console is very simple with sufficient functionality to get going. There are a couple of things that I really liked in 1.1.

• DB Manager – This portlet lets developers create, update and query the embedded database (Derby) that is shipped with geronimo. I usually use this database to store some application related information. This is very convenient to quickly check the data in the database and also allows me to write sql’s and execute them on the database, which is sweet.
• Key Stores -This portlet will let you create and manage key stores. This wizard lets you configure SSL for your server in seconds allowing you to create a key store and add your CA certs to it.

Now Geronimo 2.0.1 has been released recently and I was pleasantly surprised to see more goodies that are worth mentioning. These I believe are very helpful to Administrators and developers alike.

• JMX Viewer – A very nice tree like representation of all the different types of MBeans that are registered in the server. Each MBean is represented as a tree node that shows its attribute names, values and operations that it supports. It will also let you invoke the operations and also let you perform a simple JMX search. All MBeans are grouped by its domain. I know there are a bunch of 3rd party applications out there which provide this functionality, but coming out of the box and well integrated with the console is a different experience altogether. A screen shot is shown below.



• ClassLoader Viewer – If you are looking for a class and wondering where it came from? The class loader viewer lets you find them. I see this being very useful when it comes to ClassCastException’s and ClassNotFoundException’s. You can also perform a simple search in the portlet to find the Class you are looking for, neat!



• Dependency Viewer – You might have applications that have dependencies on external libraries in the form of JAR or compressed archive files. Also every module running on the server typically references libraries or other modules. The Dependency Viewer displays a dependency view of all modules installed and running on the server. This information is very helpful in finding and resolving duplicate dependencies, and finding any missing dependencies.



• LDAP Viewer – The LDAP Viewer helps you connect to any LDAP server and browse its contents (for read only access). I believe I do not have to mention how useful this is.

These viewer’s are so useful that I almost wish WebLogic console has all of these.. . Here’s a better idea, may be you can write one of these and donate as a console extension to the console extensions code share project. Any One?

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

A few months ago I have started the WebLogic Server Console Extensions CodeShare project on dev2dev to serve as a repository for WLS 9.x console extensions and posted a few extensions. Recently there has been a surge of enquiries about the project from various developers, wanting to join the project, asking me about how to get the source and how to submit changes to the extensions etc which indiactes that many developers/users are starting to realize the power and ease of WebLogic console extensions.
The MBeansBrowser and CustomMBeansEditor extensions have also been recently upgraded to work with WebLogic Server version 9.2 and also the code has been checked into the source repository. If you are interested in joining the project, please go here.

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

All about Silos
I am at BEAWorld and trying to salvage as much information as I can from the key notes and sessions. One interesting keyword I kept hearing and saw sprinkled all over the keynotes is “silos”. Here’s a literal dictionary meaning of silos, “A tall cylindrical structure, usually beside a barn, in which fodder is stored”. Well, this is not exactly what the keynote speaker’s meant.. . In technical terms silos mean applications, data or software’s that are built monolithically and do not participate in any common software infrastucture a company might have. The strong message from the keynote speakers at BEAWorld that kept resonating is that the BEA AquaLogic product family provides software that will let you connect disparate and unsynchronized silos of applications by employing an integration architecture and SOA to help unify a sprawling infrastructure.

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

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.

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();

WLS 9.0 Management API – part 1
In WLS 5.1 when things were much more simpler, we had a weblogic.properties file that comprised all the configuration information. None of the configuration change was dynamic, i.e if you modified a configuration parameter, to apply the change you had to re-boot the server. WLS also had an applet based console.. .
From 6.0 onwards, WLS built its Management layer on JMX 1.0 and introduced MBeans for programmatic access. The MBeans are broadly branched into 2 types, Configuration and Runtime. Configuration MBeans represented the configuration aspects of the WebLogic Server(example, ServerMBean) and the Runtime MBeans hosted all the runtime information pertaining to the Server (example, JVMRuntimeMBean). All of the configuration is stored in config.xml, which is not schema based and most of the configuration is hierarchical. WLS also started supporting dynamic change (atleast for some configuration parameters). If you made a change to the configuration, the change was applied instantaneously and the configuration file (config.xml) was updated (depending on the save domain trigger). There was only one MBeanServer that hosted all MBeans including the Configuration, Runtime and any Custom MBeans. Since in JMX 1.0 there is no remotable API to get to the MBeanServer from a client, WLS implemented MBeanHome and RemoteMBeanServer. Clients could lookup MBeanHome in JNDI and get access to RemoteMBeanServer and invoke on the MBeans.
Here’s what you would do to get to the ServerMBean.
……
Context ctx = null;
MBeanHome mbeanHome = null;
// assuming you know the user, password and url
try {
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(password);
ctx = env.getInitialContext();
mbeanHome = ( MBeanHome ) ctx.lookup(MBeanHome.LOCAL_JNDI_NAME);
ServerMBean svrBean = (ServerMBean) mbeanHome.getMBean(“myserver”,”Server”);
System.out.println(“ServerMBean retrieved “+svrBean.getName());
} catch (Exception e ) {
// handle exception
}

WLS also provided typed stubs on MBean interfaces, saving clients from writing straight JMX code. WLS introduced the WebApp based console and a command-line tool (weblogic.Admin) to manage the domain.
Well, thats the brief overview of what we had prior to WLS 9.0 Management. In my next entry we will discuss the new 9.0 management API.

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

From WLS 7.0 BEA introduced a Security Framework where you can plugin your own security providers. If you have written Security Providers against your WLS 7.0 or WLS 8.1 and you are upgrading to WLS 9.0, you will also have to Upgrade these providers before you can start using them in WLS 9.0. The security providers are available to all WebLogic domains that share a WLS installation and the default location of these providers is (WL_HOME)/server/lib/mbeantypes)
The upgrade process is pretty simple, while installation BEA even upgrades any security providers that are in the default location of previous WLS installations. If you have your provider jars in a different place (say a source control), you can upgrade them by using the Security Provider Upgrade tool. To invoke the tool use, java weblogic.Upgrade -type securityproviders, this will bring up a wizard that will walk you through the upgrade process.
A few things you will have to remember before upgrading.
1) The old provider jar should have the MDF (MBean Definition File) in the jar, a MDF is the XML file that defines your Provider MBean interface. Without this MDF file the upgrade tool has no way of finding any information about your Provider.
2) You cannot upgrade security providers that came OOTB with WLS 7.0 or 8.1, becuase these are already upgraded and available OOTB with WLS 9.0.
3) Do not be alarmed if your upgraded provider jar is little bigger in size when compared to the old, this is because the Upgrade tool generates the BeanImpl’s, BeanInfo’s, Schema information etc for your provider, such that it complies with WLS 9.0 Management Framework.
4) After upgrading, you will notice that your new provider’s name has ‘_Upgraded’ appended.

All this information is very well documented on edocs.

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