AdminContol and AdminConfig are two key scripting objects that any WAS administrator must know by heart.
The objects are available from wsadmin WAS administration tool.
AdminConfig provides an interface to the WAS configuration repository available under profile_root/config. All AdminConfig services are provided by the Deployment Manager (assuming you're connecting remotely); there is no dependency on node agents.
AdminControl provides an interface to JMX managed beans (MBeans) in your WAS environment. In general, MBeans are only available for the resources that are running. For example, if an application server is down, the corresponding MBean will not be available.
AdminConfig and AdminContol could complement each other nicely, especially when you need to find out the status of "things" in a WAS cell. To illustrate the point, here is a simple script that prints the status of all application servers within a cell:
""" List all application servers in a cell and print their status (up or down) """ # Get the string with config ids of all serves server_confids=AdminConfig.list("Server") #Iterate over all servers - config ids are separated by \n for server_confid in server_confids.split("\n"): server_confid=server_confid.strip() # obtain the type - types are APPLICATION_SERVER, DEPLOYMENT_MANAGER, NODE_AGENT, WEB_SERVER server_type=AdminConfig.showAttribute(server_confid, "serverType") # we are only interested in application servers if server_type == "APPLICATION_SERVER": # obtain the name of the server server_name=AdminConfig.showAttribute(server_confid, "name") print "Checking the state of the server %s of type %s" % (server_name, server_type) #Now we can try to get the mbean of the server. We could've used AdminConfig.getObjectName() as #a shortcut, but for the sake of the example we'll use AdminControl explicitly # Query to search for mbeans - note the wildcard at the end to match the rest of mbean parameters # Note that we're simplifying a little bit since we're ignoring node names - # server names may not be unique within cell server_query="type=Server,name=%s,*" % server_name server_mbean=AdminControl.queryNames( server_query ) # AdminContol returns None if there is no running mbean for this server if server_mbean: print "Server is up" else: print "Server is down!"
This post is part of the series on WebSphere Application Server administration. Please subscribe to this blog if you'd like to receive updates.
In one of the previous posts I complained that wsadmin tool (which is the main WebSphere Application Server administration tool) still relies on Jython 2.1, which is quite old.
The issue became critical when I realized that jython automatically re-compiles classes compiled with a different jython version. In my case, I was using Jython 2.2 for my Ant scripts and Jython 2.1 for wsadmin scripts. Some of the code was shared. This led to the situation of concurrent builds stepping on each other by dynamically re-compiling classes with different jython versions. The error looked something like that:
File "<string>", line 5, in ? java.lang.ArrayIndexOutOfBoundsException: -4 at org.python.core.imp.createFromPyClass(Unknown Source)
Bugs like that are always fun to troubleshoot.
Going back to 2.1 was not an option for me since I use closures and “new classes” in quite a few places. So I tried putting jython 2.2.1 on wsadmin classpath and it worked without a hitch with thin wsadmin client. All my of wsadmin scripts work without a problem.
Here is a sample wsadmin.bat file that I use. This file utilizes thin client jars. Note how in line 85 my jython.jar (which is jython 2.2.1) is added to the classpath so it would override jython packages supplied with WAS.
One possible downside of this approach is running into issues with IBM support in case if you need to open a PMR related to wsadmin scripting.
Using AdminTask in wsadmin often results in getting ugly stack traces. In fact, AdminTask always produces a full java stack trace even when the error is fairly innocuous (e.g., a resource name was mistyped). The stack trace in this situation is pretty useless; it could actually confuse operations staff as it might be interpreted as a problem in IBM code.
It is, in fact, quite easy to deal with this situation in Jython and suppress the annoying stack trace:
import sys from com.ibm.ws.scripting import ScriptingException ... try: AdminTask.... except ScriptingException: # note that we can't use "as" because of python 2.1 version, have to use sys print "Error:\n"+str(sys.exc_info())
I’ve started playing with WebSphere Application Sever 7.0 (the latest and greatest) and to my surprise discovered that it still uses Jython/Python 2.1 as a scripting language for its wsadmin tool.
Jython 2.2 has been around for quite a while and, from my experience, is very stable. So it’s odd that IBM choose not to upgrade it. The difference between 2.1 and 2.2 is quite significant, the biggest selling point of 2.2 is new style classes with a unified type model. Python 2.2 also supports properties. I don’t believe there is closures support in 2.1 either.
Why is it important? Well, using Java for WAS administration is hard; the API is obscure and poorly documented. This makes Jython the only game in town (with JACL deprecated some time back). So being able to use a modern version of Jython is highly desirable.
I’m still hoping that IBM might upgrade jython as part of one the minor upgrades; WAS 8.0 is probably a long time away.
Quick tips for those wishing to use thin wsadmin client with process server/WESB: add com.ibm.soacore.runtime_6.1.0.jar to the classpath.
Normally, you need the following jars for the client to work: com.ibm.ws.admin.client_6.1.0.jar, com.ibm.ws.security.crypto_6.1.0.jar com.ibm.ws.webservices.thinclient_6.1.0.jar.
However, if you want to use any of the SCA commands available in WESB, the extra jar is needed. Otherwise, you’ll be getting “class not found” for SCACommandException. The jar is available under wesb_root/plugins.
I don’t think it’s documented in infocenter.
IBM WebSphere 7 (currently in beta) comes a property-file based configuration tool that provides a "human-consumable" interface to the currently XML-based configuration repository of the application server. This is another proof that XML is simply not the right mechanism for managing configuration of complex software products.
From the release notes:
Properties (name/value pairs) files are more consumable for human administrators than a mix of XML and other formats spread across multiple configuration directories.
Kudos to IBM for recognizing that.
It is still not clear though how hierarchical relationships between configuration objects will be supported.
Back in WAS 6 world, I've been using a simple jython script that converts python named parameters into wsadmin format. This is an example of a resource described in this format:
WASConfig.DataSource(parent="testJDBCProvider", name="testDS", jndiName="jdbc/testDS", description="Test DataSource", propertySet=dict( resourceProperties=[ dict(name="dbName", value="testDB", type="java.lang.String" ), dict(name="connectionAttribute",value="", type="java.lang.String") ]))
I think that a slightly more streamlined python-based format will be superior to properties.
Most developers and administrators working with WebSphere Application Server (WAS) know that both JACL and Jython languages can be used for various WAS administration and configuration tasks. However, JACL has always been a preferred choice, simply because this is the default language used by the product's admin tool (wsadmin) and also because JACL examples and documentation are more complete.
Using JACL might have been a valid option just a few years back (when WAS just came out) given the uncertainty surrounding the Jython project. Today, however, jython is clearly alive and well; alpha version supporting Python 2.5 was announced recently. Therefore there is really no point in using JACL any longer, except may be for shops with a large collection of existing JACL scripts. JACL syntax is quite arcane compared with Python and the language is clearly not as widely used.
IBM confirmed this view by releasing JACL to Jython converter a couple years back.
Unfortunately, up until recently, jython was not officially supported in another IBM product, WebSphere Portal, which comes with wpsript tool for managing pages, deployable modules and other portal artifacts.
But since portal scripting relies on wsadmin's shell, jython is in fact fully supported by the product, it's just not documented.
All that you need to do to switch to jython is to invoke wsadmin with "-lang jython" and "-wsadmin_classpath " followed by the list of portal jars (you can copy the classpath from SCRPATH variable definition in wpscript.sh).
As an example, I put together a simple Jython script for cleaning up a portal page hierarchy. Removing pages before applying an XMLAccess script with page definitions allows to start portal configuration from a clean "known" state. Very often, especially in a development environment, an application's page hierarchy gets polluted with various "test" pages created by developers. The script gets rid of them.
In WebSphere Portal 6.1 Jython is finally made a first-class citizen. The product's documentation proclaims that JACL support will be phased out and that jython is the way to go. Surprisingly, though, all examples still use good old JACL. I assume it's just a matter of time before they are converted.