In that context, in the last few months I had inquiries from some users asking where they could find the original WLST that works with WebLogic 8.1 and 7.0, also WLST Script Generator and Console extension that work with WebLogic 9.x.

Now you can get these from the new google code project wlst-modules. WLST Script Generator 9.x can be downloaded from here. The zip contains a ReadMe.html that should walk you through the configurations steps. And for those unfortunate souls who are still using WebLogic 7.0 and 8.1, WLST jar can be downloaded from here.

For a brief description on what’s new with Jython 2.2 see my old post here.

E:\WebLogic11g\Oracle\Middleware\wlserver_10.3\common\bin>java org.python.util.jython
Jython 2.2.1 on java1.6.0_05
>>>

Expired SSL Certificates!!!My initial reaction: You don’t have Monitoring? Hmm well, that led me to think, realistically how many environments have cert expiry monitoring? I haven’t seen any environments that have automated monitors that check the WebLogic Certificates. One of the reason why this may not have affected you is one, you are not using SSL and two, the certs you obtained have a life span of more than 10 years.

In our WebLogic environments we do not have monitoring specifically on the Cert’s, but we do have some monitoring that does warn us in-case  our Certs are about to expire. The way it works is, during boot time WebLogic Server logs a message if the certs configured are about to expire in the next 30 days. This message is logged with severity “Notice”. Our monitoring application listens on the Log BroadCaster (I will leave the details for another blog post), this listener will send an alert/EMail whenever a message is logged with severity “Notice”. The alert will contain the details of what is logged, in case of a Certificate that is about to expire it will contain the Date when it is going to expire and other Certificate details.

Please note, there is one problem to the above approach, i.e. we are relying on WebLogic Server to be started or restarted atleast once within this 30 days timeframe that your Certificate may expire. If not, you will never recieve the notification.

In one of my subsequent post I will write about an alternate simple approach to monitor your WebLogic Certificates.

*sys-package-mgr*: can’t create package cache dir, ‘/tmp/cachedir/packages’
Traceback (innermost last):
File “<iostream>”, line 12, in ?
ImportError: no module named java

When Jython initializes it scans all the jar files it can find at startup to build the package and class structure available to the JVM. This information is written to files in a directory named ‘cachedir’, WLST chooses your ‘java.io.tmpdir’ to store these files. There is a problem with this approach especially on Unix machines.

Problem:

Most Unix machines are shared across a number of users. Say “user1″ first logs into the machine and fired up ‘java weblogic.WLST’, Jython will create the ‘cachedir’ under ‘/var/tmp/’ and this directory will be owned by ‘user1′. This user will have no problems using WLST. Now ‘user2′ logs in and fires up WLST, this process will try to write to the same directory, ‘/var/tmp/cachedir’ which is now owned by ‘user1′ and hence fails with the above error message.

Solution:

There is a pretty simple and straight forward solution to this problem. Jython supports a System property (python.cachedir) that you can set which will determine the directory where this ‘cachedir’ is created. So in our case to start WLST you will use,

java -Dpython.cachedir=/home/user1 weblogic.WLST

This will create the cachedir under /home/user1, and this way all users can have their own cachedir’s without running into each other. For a more elegant solution you can create a simple unix script that wraps the call to WLST and adding the right cachedir location per user. Sample is shown below,

#!/bin/sh

# Setup classpath, probably execute setDomainEnv.sh

java -Dpython.cachedir=~ weblogic.WLST

As long as the ‘~’ resolves properly to the home directory for the user executing WLST you will never have to worry about this ‘cachedir’ related error messages..

But once SSL is configured and you have dis-abled the non-ssl port, you should make sure that the DefaultProtocol your WebLogic Server uses is SSL (either t3s, https or iiops). If you haven’t done this, your WebLogic Server will try to use “t3″ (default) for any outbound connections and since the ListenPort is disabled it will fail.

Here’s a simple wlst script to change the default protocol to t3s for all the servers in the domain.

# After connecting to the Admin Server

edit()

startEdit()

servers = cmo.getServers()

for i in servers:

i.setDefaultProtocol(“t3s”)

save()

activate()

Unicast:

Unicast messaging is used for all network processes where a private or unique resource is requested making most networking traffic Unicast in form. Unicast is used where two way connections are needed to complete the network transaction.

Multicast:

Multicast addressing is a network technology for the delivery of information to a group of destinations simultaneously using the most efficient strategy to deliver the messages over each link of the network only once, creating copies only when the links to the multiple destinations split.

I believe, support for Unicast is a very important feature. Although Multicast is efficient when compared to Unicast, it causes a network configuration overhead where your Network Administrator need to dedicate a Multicast address. Also, when using Multicast you should make sure the end points or systems that don’t want the information have to be shielded from receiving these unwanted multicast broadcast messages.

Recently we have automated our Cluster configuration creations to Unicast messaging mode. In this post I would like to share wlst scripts and some guidelines to follow when using Unicast. Assuming you already have a domain, let us create a Cluster definition. First connect to the server and start an edit session

connect(uname,pwd,url)

edit()

startEdit()

 

 

 

theCluster = cmo.createCluster(‘mycluster’)

 

theCluster.setClusterMessagingMode(‘unicast’);

If you have used WLST in interactive mode I bet you are tired of typing those quotes around arguments for each command and not to mention the opening and closing brackets. Well not sure about you but I was definitely tired of this while developing WLST. Hence I have implemented a way to ease this syntax at least while navigating MBeans. The way it works is, while you are in Online mode execute the command ‘easeSyntax()’. After this, for commands like ‘cd’ and ‘ls’ you do not need to follow the jython syntax. As an example, currently to navigate to Server MBeans you will use,

cd(“/Servers/testServer”)

ls()

After executing easeSyntax() to navigate around you will use.

cd /Servers/testServer

ls

aah, I know what you are thinking. Sorry, there is no tab complete ..

import java.lang.System
encStr = encrypt(“mypassword”, java.lang.System.getenv(“DOMAIN_HOME”))

WLST internally calls the weblogic.security.Encrypt utility to encrypt the clear string. You can directly use this command line tool to encrypt the password and use the encrypted password in your scripts.