Scripting languages have recently garnered a bit of attention. With the arrival of Groovy and Jython, writing scripts merged with Java is more natural than Ant. Using XML to call Java methods has always been forced, mostly because it's hard to express flow, conditional expressions, and custom Java code in a markup language (although things have improved a lot since Ant 1.5).

Why a scripting language? Well, if I have a completely blown IDE for Java programming, using Jython or Groovy can look backwards. You can code in fewer lines (though not much less), but I want the imports written automatically. I want compiler warnings while coding and I need refactorings. Plug-ins for these languages are still outside of Java IDE's capabilities.

But there are times where you just don't have a full IDE configured. Think about jobs that should be automated to be agile, or about server administrators. These people don't have anything like Eclipse, and their work can't be done in advance. You can't code for system administration. This is where tools like WLST come in and make the world a better place.

WLST (WebLogic Scripting Tool) is a Jython module that helps write scripts to administer and modify a server installation remotely. It comes in two flavors: offline, which can configure a server instance that doesn't exist yet, and online, which needs a WebLogic server to connect to. Both versions are in beta and are poorly documented, but they promise to improve and will be in some future WebLogic release.

We're going to focus on the online version here, because its functionalities are more complete than the offline version.

Automating Server Configuration:
Let's start by getting rid of that nasty WebLogic server configuration. Your typical development team replicates the same config in several hosts, changing only a couple of parameters such as the IP, hostname, and TCP port. In a relatively typical project, the process must be executed for each developer's PC, integration test host, and production. Ant tasks resolve great in this context, but it's not prepared to handle things like custom JMX beans.

We're going to create and launch the server, configure it, and do a shutdown, using a mixture of ant and WLST. First, let's create the server in Listing 1. For simplicity's sake, we're going to use the ant task here because combining WLST offline and online would mess things up.

I check the properties because when you deploy on more than one brand of app server it's easy to use the wrong build.properties file (see Listing 2).

We have just removed the whole domain directory, created a new clean one, and left the server running, so now in Listing 3 we can connect and configure it.

The server stop is necessary because some setting changes, i.e., security authenticators, need a graceful shutdown to be stored on disk. Omitting this step would kill the server in a hard way at the end of the ant script

Note: the WLST task is forked, and so, if WLST finds an error in your script, ant still will say "build successful," something that might confuse the person launching the script.

Let's split the WLST script into two parts to reuse as much of it as possible for administration tasks later. I have used the great examples enclosed with the WLST bundle and the output of the saveDomain() command as starting points. The saveDomain() generated script isn't very polished, but it serves to indicate the tool's possibilities (see Listing 4).

The loadProperties task converts all the entries in the administration.properties file to Jython variables. We've used the first methods of a Jython class to administrate the WebLogic server instance. It can easily be extended to create and remove DataSources, a JMS environment, and even security realms.

MBean Methods
What you have seen is a way of creating and configuring MBeans (there's another way that will be explained in the next section). The downside is that you have to know the attributes and methods supported, and WLST doesn't document them. How can I guess which methods are available?

Well, the first way that comes to mind is going to the config.xml file or the web console and assume the attribute names hasn't changed. If we have a decent IDE we also can open the MBean interface class and see what's in there (it's the same as the MBean name, ending with 'MBean'). It won't show you code, but you can check which methods are available.

I prefer connecting to http://e-docs.bea.com/wls/docs81/javadocs/index.html and checking the contents of the package weblogic.management.configuration. For example, if we go to the ServerMBean class, we can see two interesting and not particularly well-known methods isJDBCLoggingEnabled() and setJDBCLoggingEnabled(). We can check them by opening the wlst interactive shell as laid out below:

wls:/mydomain/config> server=home.getAdminMBean('myserver', 'Server')
wls:/mydomain/config> server.setJDBCLoggingEnabled(1)
wls:/mydomain/config> server.isJDBCLoggingEnabled()
1

('home' is a variable of type AdminMbeanHomeImpl and can be studied as any other MBean; the only problem is that there's no javadoc available since it's an internal class).

If these last three commands aren't easily understood, don't worry. The shell will be covered in the next section.

Command Line System Administration
A system administrator can also administer the WebLogic server instance manually by using the interactive shell. The advantage here is you don't have to know a priori the MBean interfaces when trying to modify the system config. For this part, you have to include weblogic.jar, jython.jar, and wist.jar in the classpath and start the main class weblogic.WLST, which is the interactive console.

Keep it mind that this is Jython. Quotes and double quotes are used for string delimitation; instantiation doesn't need a new operator (as a matter of fact it's a syntax error); semicolons aren't required because each line ends with a carriage return; and variables don't have to be declared (a la Unix shell scripts). If that's not enough for you, please refer to the Python and WLST docs.

We need to start connecting to a WebLogic server instance. We can choose to use the AdminTool script developed before, or connect manually:

execfile('AdminTool.py')
admin.connect()

or

connect('weblogic', 'weblogic', "t3://localhost:7001)

Connecting to weblogic server instance running at t3://127.0.0.1:7001 as
username weblogic ...

Successfully connected to Admin Server 'myserver' that belongs to domain 'mydomain' is system output and should be formatted as code.

Now we can start playing with it. With WLST, the JMX tree can be traversed as a Unix filesystem, where the JMX MBeans are directories and its attributes are files. Keep in mind the Python syntax all the way through, and remember that WLST still doesn't recognize wildcards. That's the reason why we're going to omit most of the ls() output (see Listing 5).

We could have also gotten that far on a single cd('/JDBCConnectionPools/MyPool') command. WLST always remembers the cmo (Current Managed Object), the MBean corresponding to the current 'folder' we're browsing. So, these commands are equivalent from the practical point-of-view:

wls:/mydomain/config/JDBCConnectionPools/MyPool> cmo
[Caching Stub]Proxy for mydomain:Name=MyPool,Type=JDBCConnectionPool
wls:/mydomain/config/JDBCConnectionPools/MyPool> pwd()
'/JDBCConnectionPools/MyPool'

Now, let's change a couple of random properties (see Listing 6). Remember that Python doesn't have boolean attributes. The server can return true and false (since it runs Java), but you can't assign those values. Don't worry, though; if you check it through the WebLogic console, your boolean value of 1 has been interpreted correctly by the server.

You could have gotten the same result using the equivalent techniques shown in the section above about "Automating Server Configuration." I find this way easier for systems administrators, and the first way for developers preparing scripts. It just fits better in each different kind of toolset: system administrators are more used to Unix shells, and developers feel more comfortable with the "smell" of Java.

Managing the Server Configuration Example: A Real Case
It's common to need to peep inside those nasty JDBC calls. One sometimes really wants to be able to see the conversation between the WebLogic server and the database, and why in hell the query returns 0 rows, or profile performance, okay. Logging the JDBC calls (not just the SQL, please, but the parameters too) with a hot-plug capability should be nice. Wanna give it a try?

First, let's download the p6spy JDBC driver. It is a JDBC wrapper that will log anything that goes through it. To configure it, put the p6spy.jar and the directory containing the p6spy.properties in the server classpath (don't forget the directory, or WebLogic will complain as if the JAR file were not present). Tune the p6spy.properties to your needs.

What we want to achieve is the creation of two Connection Pools, one directly with Oracle JDBC driver and the other through p6spy. Then, we will change the datasource to point to the p6spy datasource without restarting the server (if we believe the Web console interface, this change does not need a reboot).

We will start by executing the administration script developed earlier:

wls:/(offline)> execfile('AdminTool.py')

Connecting to weblogic server instance running at t3://127.0.0.1:7001 as
username weblogic ...

Successfully connected to Admin Server 'myserver' that belongs to domain 'mydomain'. It also is system output and should be formatted accordingly.

We can create the Connection Pool now.

wls:/mydomain/config> admin.createPool("P6SPY Connection Pool",
"com.p6spy.engine.spy.P6SpyDriver")
JDBCConnectionPool with name 'P6SPY Connection Pool'
has been created successfully.

In the WebLogic console we can see the following (well, the WebLogic log line will only appear if you have the 'debug to console' option activated):

<28-feb-2005 20H18' GMT> <Info> <JDBC> <BEA-001132>
<Initialized statement cache of size "10"
for connection in pool "P6SPY Connection Pool".>
1109621928226|0|1|statement|SELECT 1 FROM DUAL|SELECT 1 FROM DUAL
1109621928242|0|1|statement|SELECT 1 FROM DUAL|SELECT 1 FROM DUAL

which shows the connection pool initializing and new connections test. We'll suppose that the dataSource doesn't exist yet. If we were clean, we would have foreseen it and created the method in our AdminTool class, but we can still do it via the interactive shell in Listing 7.

We have started directing the datasource to the P6SPY connection pool, so you can check your application and see that it really logs JDBC statements; try it with a test case. Now, there are two ways to disable the logging. Since we have the datasource in a Jython variable, we can do it the 'Java' way:

datasource.setPoolName(MY_POOL_NAME)

or, the 'system administrator' way shown in Listing 8.

Conclusion
WLST is an awesome tool capable of boosting your application server configuration and remote maintenance. It still lacks a find/locate option (for the not uncommon case where one needs to find a configuration option and can't recall its location) with wildcard support. But when it finally gets bundled with WebLogic 9 it's sure to be useful.

Resources