WebLogic Server Infomania

A good WebLogic Server Administration book after a very long time!

2011-11-20T06:56:00.000-08:00

Recently I was involved in reviewing a book for Packt Publishing - Oracle WebLogic Server 11gR1 PS2: Administration Essentials by Michel Schildmeijer. I am not writing this post because I reviewed this book but I had a chance to read the entire content of this book. This is a book written on the topic of WebLogic Server Administration after a very long time, and a good book too. If you are someone who works on WebLogic Server & JEE technologies you would certainly know about the scarcity of books on WebLogic Server and especially administration. WebLogic Server is being used as a commodity these days for many applications and products built on JEE platforms. Even though it is widely used there aren't many books available for WebLogic Server and the documentation serves as a good reference. But with the growing features on WebLogic Server in the past few years it is hard to learn for any new comers or who are non-developers if you are not following the product for a few years. This book comes as huge gap filler on this area.

The flow of this book would prepare you from planning to production and tuning with a good story line. As WebLogic Server is being used as the application server for almost all the Oracle Fusion Middleware Suite of products Michel not only talks in the perspective of simple JEE applications but also talks about how WebLogic fits in the Fusion Middleware area which is a key benefits that you can ripe from this book. As WebLogic is rich in features especially the administration console, I expected a bunch of screen shots and less narration when I first started reading this book for review. But Michel really balanced between the content and the screenshots, which are presented wherever it is necessary. When I used to go around training customers for BEA and Oracle in WebLogic Server, I was always in need of a white board rather than prepared presentation contents. You can clearly see that need from this book which has many diagrams hand-drawn (Of course using some tool) to explain a lot of topics.

It would say the power of this book is the take off low and fly high approach to many topics, cohesive order of the topics presented to the viewers, compilation of real world experiences and best practices.

This is a good reading if you are a Oracle WebLogic Administrator or any Oracle Fusion Middleware product administrator or trying to become one. So if you are looking to learn or reinforce your knowledge in WebLogic Server this is a good book. And this is available both in printed and electronic format.

IDE for WLST Scripting - OEPE

2011-02-17T11:29:00.000-08:00

In the past many folks asked me about a GUI based tooling support for WLST. Some people managed to use some Jython tools for WLST but it is not straight forward and supported by Oralce. What you need to author WLST scripts more efficiently is a tooling support to develop WLST Scripts. If you are involved in writing a lot of WLST scripts then you will appreciate this initiative.

Oracle just came up with a OEPE (Oracle Enterprise Pack for Eclipse) based tooling for WLST. Some of the features of this tool are:

* WLST/Jython/Python Source Editor
* Syntax highlighting, validation
* Code completion
* WLST Templates
* MBean Navigator for browsing MBeans
* WLST Execution and Console in Eclipse
* WLST integrated Help
* Support for both online and offline modes

Currently anyone who is authoring WLST scripts must refer to the docs for syntax and samples. This will be a good tool for developers so that they can build WLST Scripts within a comfortable environment - Eclipse/OEPE. Also administrators can benefit from the this tool as there are features like templates, code completion etc. The latest release of OEPE 11gR1 (11.1.1.6) comes with this tooling. To find more about the new features of this release see here.

5-Part WLST Best Practices Series

2011-02-17T11:20:00.001-08:00

A while ago I wrote a 5-part WLST Best Practices series . Here I am consolidating this post with link to all those 5 posts.

Configure Email Notification in WebLogic Server

2010-08-03T15:02:00.000-07:00

Introduction

If you are administering applications deployed on WebLogic Server or if you are operations personal responsible to manage a WebLogic Server environment you might have at least asked the following question once:

“Can I setup WebLogic Server to send automatic notifications?”

People always ask me whether WebLogic Server can send automatic notifications. My answer is - "Yes, WebLogic Server had always supported SNMP which can be configured to do standard SNMP Trap notifications to your enterprise monitoring system which can then be sent as an email or pager out to administrators". But the next question is - "I don't want to set up SNMP and I want WebLogic Server to directly send notifications. Can we do that?" Again the answer is - "Yes, starting from version 9.x WebLogic Server supports a new framework called WebLogic Diagnostic Framework - WLDF, which can be used for this purpose". Enterprise monitoring solutions like Oracle Enterprise Manager, HP Open View can monitor WebLogic Server from outside and can trigger notification among various other management and monitoring features. But you can also set up WebLogic Server to directly send many types of notifications. Let us see how to simply set up an email notification with WLS in this article.

Oracle WebLogic Server is Java EE certified application server which is the foundation of many Service Oriented Architecture (SOA) implementations. So many enterprises have their mission-critical applications deployed on WebLogic Server. WebLogic provides a scalable and highly available environment. If you are deploying your mission critical applications on Oracle WebLogic Server you can make use of WebLogic Diagnostic Framework (WLDF) to get diagnostic data from WebLogic Server instances and from applications deployed to them. This will help administrator and system operators to see more information from under the hoods.

This powerful feature will play a significant role in production environment where the application environment should alert operational personal when there is a performance or service level violation. This also eliminates the need to setup custom or third-party monitoring solutions for alerting and notification.

WebLogic Diagnostics Framework – Watch & Notification

One of the features of WLDF is Watch and Notification. You can configure server(s) with watch condition and respective notification(s) to be sent if the watch conditions are met. For example, if the number of request waiting on a JDBC Data Source to grab a connection exceeds 10 and if the free heap in the server is less than 5% then you can trigger a notification. The notification can be one or more of the following types:

JMX Notification - Application(s) can register notification listener with WLDF to receive notifications.
JMS Notification - WLDF can post a message to JMS destination to alert the situation which can be consumed by a message listener or MDBs to further processing.
SNMP Notification - SNMP traps can be sent to alert SNMP managers.
SMTP Notification - Email notifications through a Java Mail session.
Image Notification - Generates a server image which contains information from different subsystem during the watch.

Figure: 1 WebLogic Domain

You can configure Watch conditions on the MBean data, Log messages and WLDF Event data. The notification can be one or more of the above notifications. Since email notification is a common request, I shall illustrate how to setup WLS to send email notification using an open source SMTP server - The Apache Java Enterprise Mail Server (Apache James). To download Apache James, go to - http://james.apache.org/server/ [or] http://people.apache.org/dist/james/server/binaries/. Download and extract the zip file to a convenient location (Eg. /usr/james-2.3.1rcl/). Start the server using run.sh from the bin folder under the JAMES_HOME. Setup a test user in James as per these instructions - http://james.apache.org/server/2.3.1/adding_users.html. The default admin username and password for James are root/root.

Ensure that the James mail server and the administration server for the domain are started. If not, use DOMAIN_HOME/startWebLogic.cmd/sh for starting the administration server of your domain and use JAMES_HOME/bin/run.bat/sh to start James Server. You can use console or WLST to configure the following setting. Let us use the web-based administration console for configuration. Log in to WebLogic Administration Console at - http://localhost:7001/console using an administrative account.

Creating JavaMail Session

First step is to make sure that the underlying resources for the notification are setup. In this case we are going to use SMTP notification so let us first create the Java Mail Session to connect to James Mail Server.

Click "Lock & Edit" to acquire a configuration lock
Expand Services > Mail Sessions and click "New" to create a new Java Mail Session.
Provide Name, JNDI Name and JavaMail Properties as follow:
Name - James-MailSession
JNDI Name - com.test.myjamesMailSession
JavaMail Properties:

mail.transport.protocol=smtp

mail.smtp.host=localhost

mail.smtp.user=admin

mail.smpt.password=password

Click next to target the mail session to a server (Eg. AdminServer or mgd_s1) and click finish.
Activate the changes by clicking "Activate Changes".

Figure: 2 Configuring JavaMail Session

If you are using a different mail server use appropriate information.

Creating WLDF Module

Next step in configuring watch and notification is to create a diagnostic module and target it to the server. You can use console or WLST to create a diagnostic module. The following steps illustrate the steps to create a WLDF system module:

Click "Lock & Edit" to acquire a configuration lock
Click Diagnostics > Diagnostics Modules and click "New" to create a new diagnostics module. Provide a name and description.
Name - Test_WLDF_Module
Description - This is a WLDF module for testing email notifications

Select the newly created module and select targets tab. Select the appropriate server for target as before
Click "Save" and "Activate"

Figure: 3 Configuring Diagnostic Module

Creating Watch & Notification

Each WebLogic Server instance can be configured with only one diagnostic module but you can target the same diagnostic module to multiple servers or clusters. Once the WLDF system module is created and targeted to the appropriate server then watches and notifications can be configured. The following steps illustrate how to create a Watch and a Notification.

To create a watch:

Click "Lock & Edit" to acquire a configuration lock
Navigate to the diagnostic module created above (Test_WLDF_Module) and select the "Watches and Notifications" tab and "Watches" sub-tab (if not already selected)
Click "New" to create a new Watch. Provide the name and select the type as "Collected Metrics" [Select "Collected Metrics" for inspecting Runtime MBean values, "Server Log" to watch log data and "Event Data" to watch instrumented data]
Name - Heap_Watch
Watch Type - Collected Metrics
Enable Watch - Selected
Click "Next"
Click "Add Expressions"
Ensure that "ServerRuntime" is selected and click "Next"
If you are running WebLogic Server on Java HotSpot VM, make sure "Select an MBean Type from the following list" is selected and select "weblogic.management.runtime.JVMRuntimeMBean" and click "Next". If you are using JRockit VM, make sure "Select an MBean Type from the following list" is selected and select "weblogic.management.runtime. JRockitRuntimeMBean" and click "Next".
Select the instance for the appropriate server from the list for "Instance" and click "Next"
For "Message Attribute" select "HeapFreePercent", "<" for "Operator" and type "85" for "Value". Click "Finish" twice to create a Watch
Activate the changes

Figure: 4-a Configuring Watch

Figure: 4-b Configuring Watch

The above watch will trigger the configured notification if the percentage of free heap is less than 90. You could make complex rule expression by combining multiple attributes from different MBean. For now we haven't configured any notification for this watch. We will create the notification and will associate it to the watch in the following steps.

To create a notification:

Click "Lock & Edit" to acquire a configuration lock
Navigate to the diagnostic module created above and select the "Watches and Notifications" tab and "Notification" sub-tab
Click "New" to create a new Notification
Select "SMTP (E-Mail) for Type and click "Next"
Provide a name - James_Email_Notification. Make sure the notification is enabled and click "Next".
Configure the following properties for the "Config Notification - SMTP Properties" page
Mail Session Name - James-MailSession
E-Mail Recipients - admin@localhost

Click "Finish".
Activate the changes

Figure: 5-a Configuring SMTP Notification

Figure: 5-b Configuring SMTP Notification

To associate the watch and the notification:

Click "Lock & Edit" to acquire a configuration lock
Navigate to the diagnostic module created above (Test_WLDF_Module) and select the "Watches and Notifications" tab and "Watches" sub-tab (if not already selected)
Select the watch you created earlier - Heap_Watch
Select the "Notifications" tab and move the "James_Email_Notification" from Available to Chosen
Click "Save"
Select the "Alarms" tab and select "Use an automatic reset alarm". Set the "Automatic reset period" to 6 and click "Save". This will ensure that the notifications are at least 90 seconds apart.
5. Click "Activate Changes"

Figure: 6-a Associating Watch and Notification

Figure: 6-b Configuring Alarm

As we configured the watch type to be Collected Metrics, the attributes involved in the watch rule will be harvested and tested for watch rule expression(s). The default sampling period for the harvester is 300,000 milliseconds (or 5 minutes). So the time between samples will be 5 minutes. To change the sampling period for metrics collection:

Click "Lock & Edit" to acquire a configuration lock
Navigate to the diagnostic module created above (Test_WLDF_Module) and select the "Collected Metrics" tab
Ensure that "Enabled' check-box is selected
Change the "Sampling Period" as "120000" so that it will collect samples once every two minute

Figure: 7 Configuring Sampling Period

To receive the notifications sent by WebLogic Server as emails, install and configure an email client like Mozilla Thunderbird. The following is an example of the email received from WebLogic Server:

Using WLST

The configurations that are illustrated using Administration Console here can also be done using WLST. The following script is an example WLST script to configure a Javamail session, WLDF Module, Watch and Notification:


#Connect to the admin sever
connect('weblogic','Welcome1','t3://localhost:7001')
 
#Start a change session
edit()
startEdit()
cd('/')
 
#Create and configure a Javamail session
cmo.createMailSession('James-MailSession')
cd('/MailSessions/James-MailSession')
cmo.setJNDIName('com.test.myjamesMailSession')
cmo.setProperties({mail.smtp.user=user;, mail.smpt.password=password;, mail.smtp.host=localhost;, mail.transport.protocol=smtp;})
set('Targets',jarray.array([ObjectName('com.bea:Name=AdminServer,Type=Server')], ObjectName))
 
#Create and configure a WLDF Module
cd('/')
cmo.createWLDFSystemResource('Test_WLDF_Module')
cd('/SystemResources/Test_WLDF_Module')
cmo.setDescription('This is a WLDF module for testing email notifications.')
set('Targets',jarray.array([ObjectName('com.bea:Name=AdminServer,Type=Server')], ObjectName))
 
#Create and configure a WLDF Watch
cd('/WLDFSystemResources/Test_WLDF_Module/WLDFResource/Test_WLDF_Module/WatchNotification/Test_WLDF_Module')
cmo.createWatch('Heap_Watch')
cd('/WLDFSystemResources/Test_WLDF_Module/WLDFResource/Test_WLDF_Module/WatchNotification/Test_WLDF_Module/Watches/Heap_Watch')
cmo.setRuleType('Harvester')
cmo.setEnabled(true)
#For HotSpot VM
#cmo.setRuleExpression('(${ServerRuntime//[weblogic.management.runtime.JVMRuntimeMBean]com.bea:Name=AdminServer,ServerRuntime=AdminServer,Type=JVMRuntime//HeapFreePercent} < 85)')
#For JRockit VM
cmo.setRuleExpression('(${ServerRuntime//[weblogic.management.runtime.JRockitRuntimeMBean]com.bea:Name=AdminServer,ServerRuntime=AdminServer,Type=JRockitRuntimeMBean//HeapFreePercent} < 85)')
cmo.setAlarmType(None)
 
#Create and configure a WLDF SMTP Notification
cd('/WLDFSystemResources/Test_WLDF_Module/WLDFResource/Test_WLDF_Module/WatchNotification/Test_WLDF_Module')
cmo.createSMTPNotification('James_Email_Notification')
cd('/WLDFSystemResources/Test_WLDF_Module/WLDFResource/Test_WLDF_Module/WatchNotification/Test_WLDF_Module/SMTPNotifications/James_Email_Notification')
cmo.setEnabled(true)
cmo.setMailSessionJNDIName('com.test.myjamesMailSession')
set('Recipients',jarray.array([String('admin@localhost')], String))
cmo.setSubject(None)
cmo.setBody(None)
 
#Associate the watch and notification
cd('/WLDFSystemResources/Test_WLDF_Module/WLDFResource/Test_WLDF_Module/WatchNotification/Test_WLDF_Module/Watches/Heap_Watch')
set('Notifications',jarray.array([ObjectName('com.bea:Name=James_Email_Notification,Type=weblogic.diagnostics.descriptor.WLDFSMTPNotificationBean,Parent=[testdomain]/WLDFSystemResources[Test_WLDF_Module],Path=WLDFResource[Test_WLDF_Module]/WatchNotification[Test_WLDF_Module]/SMTPNotifications[James_Email_Notification]')], ObjectName))
cmo.setAlarmType('AutomaticReset')
cmo.setAlarmResetPeriod(60000)
 
#Set the sampling period
cd('/WLDFSystemResources/Test_WLDF_Module/WLDFResource/Test_WLDF_Module/Harvester/Test_WLDF_Module')
cmo.setSamplePeriod(120000)
cmo.setEnabled(true)
 
#Activate the changes
save()
activate()
 
#Exit
exit()

Using WLST Script To List Messages From A JMS Queue

2010-07-01T08:30:00.000-07:00

WebLogic Server added support for Runtime Message Management for Destination hosted on WebLogic JMS Servers in WLS 9.0. It will an exciting feature if you are currently in WLS 8.1 or new to WLS. Now you can administratively view and browse all messages, and manipulate most messages in a running JMS server, by using the Administration Console or WLS public runtime APIs. Once I start getting excited about this feature to customer the very next logical question from administrators are can I script this? The answer is obviously, Yes. Java or WLST is your answer. If you are a developer and there is a requirement to provide a Java/JEE application for your administrators or business users to view or browse the messages then Java will be your option. For administrators who are non-Java, there are MBeans like JMSDestinationRuntimeMBean and JMSDurableSubscriberRuntimeMBean that you can use from WLST to script any of the message managment features. Needless to say if there are existing Java implementation for message management then you can simply import and use them within WLST as well. But WLST scripts are natural choice for administrators.

So I started out writing a simple WLST script that can list all the messages from a given JMS Queue. The script is written to list all the headers and properties along with the body. I have made enough comments in the script to explain the different steps. But the high-level steps are:

Connect to the server
Get to the JMSDestinationRuntimeMBean
Get the cursor to find the number of messages
Get the messages without body to find the cursor and the Message ID
Get the message with body using the Message ID
Print the Headers, Properties and Body (or) Pay Load of the Message

A key information to note here is if you have any Object Messages in the Queue then those classes should be added to the Java Classpath before you execute this WLST Script. I haven't implemented any exception handling logic in my script whereas handling exceptions are best practices and you might want to refer to my other entries regarding that information.


#Import necessary classes/interfaces
from weblogic.jms.extensions import JMSMessageInfo
from javax.jms import TextMessage
from javax.jms import ObjectMessage

#Define constants
url='t3://localhost:7001'
username='weblogic'
password='weblogic1'
jmsservername='test-jms-server'
jmsmodulename='test-jms-module'
jmsdestname='test-queue'

#Connect
connect(username,password,url)

#Switch to the server runtime tree
serverRuntime()

#Navigate to the JMS Destination Runtime MBean
cd('JMSRuntime/' + serverName + '.jms/JMSServers/' + jmsservername)
cd('Destinations/' + jmsmodulename + '!' +  jmsdestname)

#Get the cursor (JMSMessageCursorRuntimeMBean) to browse the messages - No selector & No time out
cursor = cmo.getMessages('',0)

#Determine the number of messages in the destination
cursorsize = cmo.getCursorSize(cursor)
print '------------------------------------------'
print 'Total Number of Messages -> ', cursorsize
print '------------------------------------------'

#Get all the messages as an array of javax.management.openmbean.CompositeData
messages = cmo.getNext(cursor, cursorsize)

#Loop through the array of messages to print
for message in messages:

#Create WebLogic JMSMessageInfo to get Message ID
jmsmsginfo = JMSMessageInfo(message)
wlmsg = jmsmsginfo.getMessage()
wlmsgid = wlmsg.getJMSMessageID()

#Get Message with body
fullcursormsg = cmo.getMessage(cursor,wlmsgid)
fulljmsmsginfo = JMSMessageInfo(fullcursormsg)
handle = fulljmsmsginfo.getHandle()
compdata = cmo.getMessage(cursor, handle)
msgwithbody = JMSMessageInfo(compdata)

#Print Key Message Headers
print 'Message ID           - ' + msgwithbody.getMessage().getJMSMessageID()
print 'Message Priority     -' , msgwithbody.getMessage().getJMSPriority()
if msgwithbody.getMessage().getJMSRedelivered() == 0:
    redeliv = 'false'
else:
    redeliv = 'true'
print 'Message Redelivered  - ' + redeliv
print 'Message TimeStamp    -' , msgwithbody.getMessage().getJMSTimestamp()
print 'Message DeliveryMode -' , msgwithbody.getMessage().getJMSDeliveryMode()

#Print Message Properties
prop_enum = msgwithbody.getMessage().getPropertyNames()
print ' '
print 'Message Properties   :'
print ' '
for prop in prop_enum:
    print prop + ' - > ' + msgwithbody.getMessage().getStringProperty(prop)

#Print Message Body
fullwlmsg = fulljmsmsginfo.getMessage()
print ' '
print 'Message Body         :'
print ' '
if isinstance(fullwlmsg, TextMessage):
    print fullwlmsg.getText()
else:
    if isinstance(fullwlmsg, ObjectMessage):
        print fullwlmsg.getObject()
    else:
        print '***Not a Text or Object Message***'
        print fullwlmsg.toString()
print ' '
print '--------------------------------------------------------------'
print ' '

#Close cursor as No Time Out specified - Best practice
cmo.closeCursor(cursor)

#Disconnect & Exit
disconnect()
exit()

Running OS Commands From WLST

2010-06-16T14:39:00.000-07:00

If you spend a lot of time with WLST in the interactive mode, I am sure you have opened another command prompt/shell to check something at the OS file system level. If you wonder whether can execute an OS command from within WLST prompt, the answer is "Yes". This is very convenient similar to how you can execute OS commands from within "Vi" editor.

In fact this feature is not from WLST but from underlying Jython. There is "os" module in Jython that provides a unified interface to a number of operating system functions. There is "system" function in the "os" module that can take a OS command as a string input and returns either "0" or "1" depends on whether the command was successful or failed. So this feature can also be used with scripting mode where the return code can be verified for further processing in the script.

For eg. os.system(r'dir c:\bea') can list the contents of the bea folder under c drive. Notice the use of the preceding 'r' for escaping the entire string.

Effective HTTP Session Monitoring in WebLogic Server With monitoring-attribute-name

2010-04-22T08:37:00.000-07:00

Monitoring HTTP Session on WebLogic Server is one of the common task for administrators when monitoring web applications for performance or for activity or usage. Web application modules deployed to WebLogic Server maintains a "monitoring ID", which although looks like a session ID is not the same as the real session ID. You can use the monitoring id to identify the session uniquely. Monitoring IDs are not same as session IDs for security reason. You can turn on session debugging which prints session IDs to the log but these will not match what you see in the console/WLST. Monitoring ids are randomly generated by default. You can set a value to this monitoring id through a session attribute using "monitoring-attribute-name" element in session-descriptor of the weblogic.xml. This can simplify the task of monitoring sessions for administrators in production environment.

For e.g. if you set the "monitoring-attribute-name" to be "user-name" then it will use the string value of the session attribute named "user-name" as the value for Monitoring ID instead of the randomly generated value. When getMonitoringID(sessionid) method is called on the ServletSession, it will return session.getAttribute("user-name").toString().


weblogic.xml
-------------
...
    
     600
     user-name
    
    
    
 true
    
...

So if you have an attribute within the HTTP Session which can identify the user/session uniquely then you can use that as the monitoring id. This is the recommended approach to track/monitor sessions instead of the session id which is an internal attribute. If you don't set the monitoring-attribute-name, WLS will randomly generate a monitoring id for each session. When developers set the monitoring-attribute-name, this will help administrator to associate sessions to the actual users.

Sample WLST script to get all the monitoring ids (for the respective session) as an array:


...
AppName = 'MedRecEar'
TargetServerName = 'MedRecSvr1'
WebCompName = 'MedRecWar'
serverRuntime()
cd('ApplicationRuntimes/' + AppName + '/ComponentRuntimes/' + TargetServerName + '_/' + WebCompName) MIDs = mon_ids = cmo.getServletSessionsMonitoringIds()
...

In the above example, the variable mon_ids will contain an array of monitoring ids as strings. Using these monitoring ids information about the individual session can be obtained from other operations like:
- getSessionLastAccessedTime
- getSessionMaxInactiveInterval

One can even invalidate the session using the following opertion:
- invalidateServletSession

This will give an option for administrators to cleanup or delete stale sessions if there are any. These are the only information that are exposed for sessions unless you want to use the deprecated ServletSessionRuntimeMBeans. This is an old MBean that has more methods/operations. Admin console doesn't expose the session id for security reason. If you need access to all the session ids for some reason then you have to use this deprecated ServletSessionRuntimeMBeans. You can get all the ServletSessionRuntimeMBeans as an array from a WebAppComponentRuntimeMBean using a deprecated getServletSessions() method. WLST script to access the above mentioned deprecated ServletSessionRuntimeMBeans:


...
AppName = 'MedRecEar'
TargetServerName = 'MedRecSvr1'
WebCompName = 'MedRecWar'
serverRuntime()
cd('ApplicationRuntimes/' + AppName + '/ComponentRuntimes/' + TargetServerName + '_/' + WebCompName + '/ServletSessions')
ls()
....

The above ls() command will list you all the sessions with session id as their name. Even though this post has lot of information on how to monitor sessions and make use of the monitoring-attribute-name, I shall write another to provide a complete example of how to use this.

Also see my other post on how to monitor HTTP sessions from the administration console and WLST.

User Lockout & WLST

2010-04-21T17:57:00.000-07:00

WebLogic server provides an option to lockout users to protect accounts from password guessing attack. It is implemented with a realm-wide Lockout Manager. This feature can be used with custom authentication provider also. But if you implement your own authentication provider and wish to implement your own lockout manager that is possible too.

If your domain is configured to use the user lockout manager the following WLST script will help you to:
- check whether a user is locked using a WLST script
- find out the number of locked users in the realm


#Define constants
url='t3://localhost:7001'
username='weblogic'
password='weblogic'
checkuser='test-deployer'

#Connect
connect(username,password,url)

#Get Lockout Manager Runtime
serverRuntime()
dr = cmo.getServerSecurityRuntime().getDefaultRealmRuntime()
ulmr = dr.getUserLockoutManagerRuntime()

print '-------------------------------------------'
#Check whether a user is locked
if (ulmr.isLockedOut(checkuser) == 0):
 islocked = 'NOT locked'
else:
 islocked = 'locked'
print 'User ' + checkuser + ' is ' + islocked

#Print number of locked users
print 'No. of locked user -> ', Integer(ulmr.getUserLockoutTotalCount())

print '-------------------------------------------'
print ''

#Disconnect & Exit
disconnect()
exit()

WLDF Browser

2010-02-26T14:15:00.000-08:00

WebLogic Diagnostic Framework (WLDF) is a comprehensive framework for diagnosing isuees related to servers, applications, services in WebLogic Server. Image capturing is a component of WLDF which can be used to get a snapshot of all the key information from a server. The WLDF Image gets generated as a zip file with an "img" file for information from each sub-system. For more information regarding WLDF Image capturing refer to the WLS documentation here.

Currently there are no official tools available to view the image or to compare 2 or more images. The attached tool WLDF Browser can help you to view the diagnostic image.

HTTP Session Monitoring in WebLogic Server

2010-02-26T10:53:00.000-08:00

Monitoring HTTP sessions on WebLogic Server is a common task when you have web component (WAR) deployed as a part of your enterprise application (EAR). By default WebLogic Server provides a way to access the number of active HTTP sessions for each web application. But if you need more information about the individual sessions like their creation time, last accessed time, maximum inactive interval etc. then you have to enable the session monitoring option in the web component's Deployment Descriptor (DD). If the application is already packaged and deployed you can make use of the deployment plan to enable this attribute. WebLogic Administration Console provide options to modify some of the attribute for the components and application through the interface. Eventually a deployment plan will be generated if there are no deployment plan associated with the application or the existing plan will be modified automatically by Administration Console. This will ease administrators job of enabling session monitoring for a packaged application. You may have to update or redeploy the application with the plan for the monitoring to take effect. No restarting of any server is required for this change.

Administration Console will automatically populate the Session tab under the Monitoring tab with the individual session information for the specific application. By default the following column are displayed on the console page:

Context Root
Server
Creation Time
Time Last Accessed
Max Inactive Interval

You can also add the following columns to the table by customizing the view:

Monitoring ID
Application
Machine

The Monitoring ID provides a unique ID by default to identify the session. You can also customize the Monitoring ID by specifying a session attribute name which is unique for identifying the session for users. For example you can configure customer_id or user_id or order_id as Monitoring ID for tracking session. I shall talk about Monitoring IDs and finding session size in a different post. Internally WebLogic will concatenate the Monitoring ID with the creation time to make a unique name for each session. The following is an example screen shot of monitoring sessions after customizing the view:

WLST can also be able to retrieve these information from the ServletSessionRuntimeMBeans. The following is an example WLST script to connect to the Administration Server of a domain to retrieve session information for a specific application on a particular server.I had used the deprecated ServletSessionRuntimeMBeans in my WLST example as the session creation time is only available through that runtime mbean. You can also access all the information about the session except the creation time through the WebAppComponentRuntimeMBean. But you will have to use the Monitoring IDs (available through WebAppComponentRuntimeMBean) to get information about a specific session.


from java.util import Calendar

def defineVariables()
  #Define all the variables used
  username='system'
  password='weblogic'
  adminurl='t3://localhost:7001'
  servername='AdminServer'
  appname='CompanyStore'

def connectToAdminServer()
  #Connect to Admin Server
  connect(username,password,adminurl)

def extractAndPrintSessionInfo(servletSessionRuntime)
  #Get session name
  session_name=ssession.getName().split('!')[0]
  #Creation time is concatinated to the session name. So split it
  ct_millis=ssession.getName().split('!')[1]
  cal = Calendar.getInstance()
  cal.setTimeInMillis(Long(ct_millis))
  ct = cal.getTime()
  #Get last accessed time
  tla_millis=ssession.getTimeLastAccessed()
  cal.setTimeInMillis(Long(tla_millis))
  tla = cal.getTime()
  print ' '
  print 'Session Name - ' + session_name
  print 'Creation Time - ', ct
  print 'Last Accessed Time - ', tla

#Main
defineVariables()
connectToAdminServer()

#Get Runtime for our server
domainRuntime()
cd('/ServerRuntimes/'+servername)

#Get all running applications
apps=cmo.getApplicationRuntimes()
for app in apps:

  #We are intersted only on this application
  if app.getName() == appname:
  
    print 'Application Name - ',  app.getName()

    #Get all components in that application
    comps=app.getComponentRuntimes()
    for comp in comps:

      #We are interested in only web components
      if comp.getType() == 'WebAppComponentRuntime':
        comp_name = comp.getName().split(servername+'_/')
        if len(comp_name) == 1:
            display_comp_name = '(default web app)'
        else:
            display_comp_name = comp_name
        print 'Component Context Root - ', display_comp_name
  
        #Get all active sessions
        sessions=comp.getServletSessions()
        print 'Total no. of sessions - ', len(sessions)
 
        #Loop through all the available sessions
        for ssession in sessions:
            extractAndPrintSessionInfo(session)

#Disconnect and exit
disconnect()
exit()

The output from the above script will look something like this:


[test@mywlssvr-orcl ~]$ java weblogic.WLST sessions.py

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Connecting to t3://localhost:7001 with userid system ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'dizzyworld'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Application Name -  CompanyStore
Component Context Root -  (default web app)
Total no. of sessions -  2

Session Name - dYvLLHgRGxQ8zS0ZYySLZKx1j2KK9Ws2G22nlJXvrQRFv64zsPTm
Creation Time -  Fri Feb 26 01:13:21 UTC 2010
Last Accessed Time -  Fri Feb 26 01:13:26 UTC 2010

Session Name - nGbTLHgFLnfNjwGT1cpHGQhJZGZynBYRsp2TjC8kC7KFRK1vCCf3
Creation Time -  Fri Feb 26 01:13:41 UTC 2010
Last Accessed Time -  Fri Feb 26 01:13:45 UTC 2010
Disconnected from weblogic server: AdminServer


Exiting WebLogic Scripting Tool.

Node Manager as a UNIX Startup Process

2010-01-23T13:54:00.000-08:00

Configuring WebLogic Server (WLS) as a startup process was a common administrative process in the past. But after Node Manager (NM) was introduced as an agent to start, stop, restart and monitor WebLogic Server it is now recommended that you start WebLogic Server using NM. But NM has to configured as a startup process on the respective OS so that it is always running to manage the respective WLS instances on that machine. NM can either be Java based NM or Script based NM. Script based NM uses OS services like SSH or RSH to execute the NM script. But Java based NM is a Java process that should be started. So setting up NM as a service will ensure that NM is always running. There is a lot of information in the WebLogic Server documentation about setting up NM. But there is very less or no information about setting NM as a service on a non-Windows environment. For Windows environment there are pre-packged scripts that you can use. These scripts exists under WL_HOME/server/bin folder (installNodeMgrSvc.cmd, uninstallNodeMgrSvc.cmd). But for UNIX based environment you should do this manually or with the help of OS specific utilities like chkconfig etc.

For *nix environment NM should be configured as startup process using rc scripts. Creating rc scripts for configuring NM as a service is even simpler than configuring WebLogic Server as a service. This is mainly because NM doesn't have to be shutdown gracefully. All you have to do is write a simple shell script that starts the NM and create the symbolic link to that script from the right run level folder. The following illustrates the steps to confiure NM as service under LINUX environment. It should be very similar on other *nix environments. You need root permission to peform the following steps.

1. Create a shell script (wlsnmd) under /etc/init.d/ folder:


#! /bin/bash
case "$1" in
    start)
        WL_HOME = /usr/middleware/11.1.0/wlserver_10.3
        $WL_HOME/server/bin/startNodeManager.sh
        ;;

    *)
        echo "Usage: $0 {start}"
        exit 1
esac

exit_status

2. Assuming that we are going to start NM at run level 5, create a sysmbolic link in /etc/rc.d/rc5.d/ folder. Since it a startup script we should start the symbolic link with "S" and followed by a number which decide the order in which services will be called. As we are fine to start NM after all the other application/services are start let us choose 99 which is the highest number.



ln -s /etc/init.d/wlsnmd S99weblogic

If you don't want to do these manually you can also use utilities like chkconfig (included in Red Hat distributions) for managing your startup scripts. For configuring WebLogic Server as a startup process there are pre-packaged scripts (installSvc.cmd, uninstallSvc.cmd). But you have to create rc scripts similarly for WLS as well in UNIX based environments. Here is an example rc script for configuring a WebLogic Server as a startup process. But here we also need to implement the kill/stop to gracefully shutdown the server.



#! /bin/bash

case "$1" in
    start|reload)
        DOMAIN_HOME = /usr/middleware/domains/med_analysis
        $DOMAIN_HOME/bin/startWebLogic.sh
        ;;
    stop)
        $DOMAIN_HOME/bin/stopWebLogic.sh
        ;;
    restart|force-reload)
        $0 stop
        $0 start
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

exit_status

Understanding WLST built-in variables . . .[WLST scripting Best Practices (Part-5)]

2009-11-25T14:20:00.000-08:00

This post is a continuation of my previous post - in a series of posts about WLST scripting best practices.

Managed Beans (MBeans) are used to represent all the configuration and runtime information about WebLogic Domain, Servers, the applications and services deployed on a WebLogic Server Domain. While you can get all the information from WebLogic MBeans, WLST simplifies the task of building scripts by providing some built-in variables. These WLST variables are initialized and/or modified when you change to online mode (connect to a server), start an edit session etc. to appropriate values.

One of the very useful WLST variable is cmo. cmo stands for current management object. When navigating in WLST you can use cmo to reference the current MBean (object) instance you are navigating into. The cmo value is changed when you navigate to different hierarchy of MBeans under different MBean trees in WebLogic (except jndi tree). The following illustrates the use of cmo.


...
connect(username, password, url)
edit()
startEdit()
cd('/Servers/server1')
s1=cmo
cd('/Servers/server2')
s2=cmo
print 'Listenport of server1 -> ' + s1.getListenPort()
print 'Listenport of server2 -> ' + s2.getListenPort()
...

Notice the use of cmo can for invoking operations on the respective MBean object. There are many such variables that will help you to write better and efficient WLST scripts. See here for the list of all the WLST variables.

If you know a variable name you can simply use it in you script. dumpVariables() command can be used to list all the variables and their values.


wls:/testdomain/serverConfig> dumpVariables()
adminHome                     weblogic.rmi.internal.BasicRemoteRef - hostID: '328889774891021637S:127.0.0.1:[7001,7001,-1,-1,-1,-1,-1]:testdomain:AdminServer',oid: '259', channel: 'null'
cmgr                          [MBeanServerInvocationHandler]com.bea:Name=ConfigurationManager,Type=weblogic.management.mbeanservers.edit.ConfigurationManagerMBean
cmo                           [MBeanServerInvocationHandler]com.bea:Name=testdomain,Type=Domain
connected                     true
domainName                    testdomain
...

In addition you should also be aware of these WLST variables in order to NOT use them to store your own information. If you do so then WLST will overwrite these variables during your interaction like connect, startEdit etc. So make sure you understand these WLST variables, use them in your scripts and do not use them to store your information.

Force confidentiality for Web Applications

2009-11-23T08:54:00.000-08:00

Usually there are requirements for web based applications to use SSL when serving sensitive data between the client browser and WebLogic server. You can enable SSL port for WebLogic Server and disable the plain text port. This will force all the communication through the SSL port enabled on the target server. But if you have a mix of applications that require secured access and that doesn't then you can use the standard JEE web application descriptor to enable confidentiality. If you enable trasport guarantee configuration for the Web Applications, WebLogic Server will force the application or selective URL patternts to be accessed through the SSL port on WebLogic Server.

The following shows an example of transport guaranetee entry from web.xml:


...

   
       CONFIDENTIAL
   

   
       /*
   

...

Even if the client is accessing through plain text port, WLS container will automatically redirect the request to the SSL port if enabled or to any other Network Channel enabled with SSL. This will ensure that certain applications or requests to be always accessed through SSL. Setting the transport guarantee to be NONE will relax the requirements and will not force SSL for the applications. But if there are SSL enabled network channels or SSL port is enabled on the server then the application can still be accessed using SSL. If the value for transport guarantee is set to be INTEGRAL then the requirement is that the data sent between the client and server be sent in such a way that it can't be changed in transit.

Needless to say that this configuration can also be configured through deployment plans. If the application you are deploying on WebLogic Server is already packaged for deployment or third-party application then deployment plan will solve the purpose of overriding the application's configuration through external means. See here for more information on deployment plans with WebLogic Server.

More ways to check the existense of a resource with WLST

2009-10-22T15:15:00.000-07:00

In one of my previous post, I discussed a couple of ways with which you can find out whether a particular configuration already exists before you create them. The methods are not just limited to the one on that post. So now I am here to discuss couple more way to do the same check. But just for completeness I shall also include the methods I discussed in my previous post. I am taking a sample use case to check whether a particular WebLogic Server instance exists in the domain or not. But you can extrapolate these technique for any other resource like JDBC Data Source, JMS Server, JMS Queue etc.

Goal - Check whether a server with the name 'mymanagedserver' exists in the domain

Method-1 Using "cd"

A simple approach is to use the "cd" command to navigate into that configuration MBean. If the "cd" command throws an exception then you can safely assume that the resource/configuration doesn't exists and you can continue with your task.


...
mgdServerName = 'mymanagedserver'
### Checking for the server
try:
 cd('/Servers/' + mgdServerName)
 print '===> Server \"' +mgdServerName+'\" already exists'
 print '===> No action was performed'
 exit()
except:
 pass
### Continue to create the server
...

Method-2 Catch "BeanAlreadyExistsException"

Another approach is to catch the "BeanAlreadyExistsException" when creating the resource and safely exiting the script.


...
mgdServerName = 'mymanagedserver'
### Create the Managed Server
edit()
startEdit()
try:
 create(mgdServerName, resourceType)
 print '===> Created Managed Server - ' + mgdServerName
 pass
except BeanAlreadyExistsException:
 print '===> Server \"' +mgdServerName+'\" already exists'
 print '===> No action was performed'
 cancelEdit('y')
 exit()
...

But with this approach you are starting an edit session and creating the server to find out it's existence. So you have to cancel the edit session once you find out that the resource that you are creating already exists if not you might get a warning message similar to the following:

You have an edit session open and you will lose all outstanding changes and your edit session will be stopped if you exit. Are you sure you would like to exit? (y/n)

So canceling the edit session with a response 'y' will make WLST not to prompt for the user response.

Method-3 Using "getMBean"

There is a WLST command called getMBean which will return the MBean object when you specify the appropriate path. If the instance is not found then it will return None. But getMBean command does not throw an exception when an instance is not found. So you have explicitly check result of the getMBean.


...
mgdServerName = 'mymanagedserver'
ref = getMBean('/Servers/' + mgdServerName)
if(ref != None):
print 'Server ' +  servername + 'already exists'
disconnect()
exit()
else:
pass
### Continue to create the server
...

Method-4 Using "ls"

You can simply navigate to the resource type and execute ls. This will return the list of all the instances as a string when you assign the output to a variable. Then you can use the find method on that string variable to check whether your server exists. The find method returns a "0" on success or "-1" on failure.


...
mgdServerName = 'mymanagedserver'
cd('/Servers')
servers = ls()
if (servers.find(servername) != -1):
print 'Server ' +  servername + ' already exists'
disconnect()
exit()
else:
pass
### Continue to create the server
...

Don't want to get prompted for confirmation in WebLgic Console?

2009-09-16T08:09:00.000-07:00

If you are using WebLogic Admin console frequently to configure resources or to manage the life cycle of the servers, you might have seen a confirmation prompt. This prompt will show not up when you are running the domain in development mode. When the domain is running in production mode they will ask confirmation for all the operations. There used to be no way to disable this confirmation page prior WebLogic Server 10.3. Now in WebLogic Server 10.3 and higher you can set a console user preference that can disable these confirmation pages.

Use the tool bar at the center (top) of the console to go to the "Preferences". Under the "User Preferences" tab you will find an option called "Ask for confirmation in operations". By default it will be enabled in production domains and you can disable it to avoid that annoying confirmation pages where will have to click either "Yes" or "No". While you are there explore the other useful preferences like "Show Inline Help" and "Show Advanced Sections" which can buy some real-estate space in the console and save you some clicks.

Change in WebLogic Server HTTP Session Failover Logic With Proxy Plug-ins

2009-08-28T10:07:00.000-07:00

When using HTTP Sessions with WebLogic Cluster, you can ensure high availability for your session by configuring HTTP Session Replication. For the replication strategy, you have many options to select from like In-memory, file, JDBC, Cookie etc. When you are using in-memory replication with a web server to front WebLogic Server Cluster, the proxy plug-in must be configured on the web servers. The proxy plug-ins are intelligent enough to stick the request from a client to the same server where the session is hosted. A secondary copy of the session will be sent to a backup server by the primary server. This information will be written to a cookie or encoded in the URL depending on the client's configuration to support cookies.

In the past, during failure of the primary server, the proxy plug-in on the web server will redirect the request to the secondary/backup server. This resulted in increased traffic to the secondary/backup server. So somewhere during the Weblogic Server 9.x the plug-ins are updated to do a random routing incase of failures. The proxy server will randomly distribute all the requests from the failed server to different servers that are still running in the cluster. When the request from the existing clients (with valid session id) gets redirected to servers that are not secondary server then that server will connect to the secondary server for that client and will pull the session to become primary server. This ensures that one server will not get overloaded when a server in a cluster fails.

The same exact strategy was used when you front a WebLogic cluster with a load balancing hardware as not all the load balancing hardware understand the WebLogic cluster configuration. Now the same strategy is applied to the WebLogic Cluster front by a proxy plug-in hosted on a web server. This make the failover strategy consistent whether you have hardware or a software based proxy in front a WebLogic Cluster.

WebLogic Server documentation is still not updated to reflect this change under the "Proxy Failover Procedure" section. If you are running WebLogic Cluster with 9.x and you are not seeing this behavior then you can contact Oracle Support to find out whether there is a patch that can you can apply for your current WebLogic implementation.

Use definitions for Reuse [WLST scripting Best Practices (Part-4)]

2009-06-01T12:19:00.000-07:00

This post is a continuation of my previous post - in a series of posts about WLST scripting best practices. When you are authoring WLST scripts for automating WebLogic administration tasks, you can reuse or extend an existing logic written in WLST or Jython scripts. You can also leverage or extend logic written in Java which I will discuss later in a different post. Definition are reusable code blocks in Jython. Think of definitions as methods or functions. You can pass parameters into definitions. You can reuse definitions from the same script or from a different script. A script that contains definitions for other scripts to use is usually called as a 'Module'. If you are using a definition from a module then you should import it in your script. The definition should be defined before they get called in the script.

Let us see an example of a using definition in the same script.


#Definition for connecting to a server
def connectToServer():
    username = 'weblogic'
    password = 'weblogic'
    url = 't3://egAdm:7001'
    connect(username, password, url)

#Definition to print a running servers heap details
def printHeapDetails(server_name):
    domainRuntime()
    cd('/')
    cd('ServerRuntimes/'+server_name+'/JVMRuntime/'+server_name)
    hf = float(get('HeapFreeCurrent'))/1024
    hs = float(get('HeapSizeCurrent'))/1024
    hf = hf/1024
    hs = hs/1024
    print 'HeapFreeCurrent - ' + `hf` + 'MB'
    print 'HeapSizeCurrent - ' + `hs` + 'MB'

#Definition to disconnect from a server
def disconnectFromServer():
    disconnect()
    exit()

#Calling connectToServer definition with no arguments
connectToServer()

#Calling printHeapDetails with arguments
printHeapDetails('AdminServer')
printHeapDetails('mgds1')
printHeapDetails('mgds2')

#Calling disconnectFromServer definition with no arguments
disconnectFromServer()

In the above script we are connecting to the administration server of a domain and then printing the heap details for the admin server and 2 other managed servers. The logic to navigate to the respective runtime mbean and printing the heap related attributes is being defined as reusable definition and called multiple times.

WLST-BP-4 Use definitions for Reuse

Reading csv File in WLST Script

2009-03-23T18:48:00.000-07:00

One of the comment for an earlier post was about creating domain(s) from csv file with WLST. Creating domain using WLST is a fairly simple and straight forward process. So I decided to explain the simple concept of reading a csv file and creating a domain using an example.

The main trick is to use the Jython language libraries to perform some of the required operations. In my example I shall illustrate how to read command-line arguments, open and read files using Jython. I am also using some local function definitions to create some modular script here. The following is an example of a comma seperated value file that our WLST script can read to create one or more domains:


#domainName,domainLocation,adminUser,adminPassword,adminServerAddress,adminServerPort
testDomain,/home/oracle/domains,system,weblogic,localhost,8998
anotherDomain,/home/oracle/domains,system,weblogic,localhost,7887

Comment lines start with # and each line that is not a comment line represent values for a domain such as domain name, location etc. The script to read the csv file and create the domain can be something like this:


### Script to create WebLogic Domain(s) from csv file
### Reusable Definitions
def buildDomain():
    ### Read Basic Template
    readTemplate(WL_HOME+"/common/templates/domains/wls.jar")
    cd('Servers/AdminServer')
    set('ListenAddress', adminServerAddress)
    set('ListenPort', int(adminServerPort))

    ### Create Admin User
    cd('/')
    cd('Security/base_domain/User')
    delete('weblogic','User')
    create(adminUser,'User')
    cd(adminUser)
    set('Password',adminPassword)
    set('IsDefaultAdmin',1)

    ### Write Domain
    setOption('OverwriteDomain', 'true')
    writeDomain(domainLocation+'/'+domainName)
    closeTemplate()

def printConfirmation():
    ### Print Confirmation
    print ""
    print "Created Domain With Following Values"
    print "Domain Name   = %s " % domainName
    print "Domain Location  = %s " % domainLocation
    print "Admin User   = %s " % adminUser
    print "Admin Password   = %s " % adminPassword
    print "Admin Server Address  = %s " % adminServerAddress
    print "Admin Server port  = %s " % adminServerPort

### Executable Script 
### CreateDomain.py
import sys

### Define constants
WL_HOME = "/products/beaSB/wlserver_10.0"

### Read the command-line arguments
argslength = len(sys.argv)
if argslength < 2 :
    print '==>Insufficient arguments'
    print '==>Syntax: java weblogic.WLST CreateDomain.py csv.file'
    exit()
else:
    ### Read the csv file
    fileName = sys.argv[1]
    print('Reading File \"' + fileName + '\"' )
    f = open(fileName)
    try:
        for line in f.readlines():
        ### Strip the comment lines
        if line.strip().startswith('#'):
            continue
        else:
            ### Split the comma seperated values
            items = line.split(',')
            items = [item.strip() for item in items]
            if len(items) != 6:
                print "==>Bad line: %s" % line
                print "==>Syntax: domainName, domainLocation, adminUser, adminPassword, adminServerAddress, adminServerPort"
            else: 
                (domainName, domainLocation, adminUser, adminPassword, adminServerAddress, adminServerPort) = items
  
                ### Call the definition buildDomain
                buildDomain()

                ### Call the definition printConfirmation
                printConfirmation()

    except Exception, e:
        print "==>Error Occured"
        print e
exit()

The executable part of the script is something that is not marked as a definition and in this case it start with the import statement. Any command-line or program arguments passed to WLST are available through sys.argv array. The array is zero indexed and the first element of the array sys.argv[0] is the script file itself. In our script we check to make sure that atleast 2 arguments including the script filename exists.


...
### Read the command-line arguments
argslength = len(sys.argv)
if argslength < 2 :
    print '==>Insufficient arguments'
    print '==>Syntax: java weblogic.WLST CreateDomain.py csv.file'
    exit()
else:
...

Built-in functions are then used to open and read the csv file.


...
f = open(fileName)
try:
    for line in f.readlines():
...

We are Using the startswith to eliminate the comment lines and then using the split and strip string function to create a list of all the items passed from the command-line. Later after checking the number of values in each line the list is assigned to a tuple of variable names (tuple is immutable in Jython where as Lists are mutable).


(domainName, domainLocation, adminUser, adminPassword, adminServerAddress, adminServerPort) = items

Once we have all values read and stored in the respective variables then it is pretty straight forward to create a domain which in this case was built as function definition (buildDomain). Later all the values were sent to standard output for user's attention. Also any exception will be reported with the try...except block.

Check for resource/configuration existence [WLST scripting Best Practices (Part-3)]

2009-03-02T05:44:00.000-08:00

This post is a continuation of my previous post in a series of posts about WLST scripting best practices. When you are authoring WLST scripts to create new resource/configuration in WebLogic domain then check for its existence. If the resource/configuration already exists then you might get an error similar to the following:

weblogic.descriptor.BeanAlreadyExistsException: Bean already exists

A simple approach is to use the "cd" command to navigate into that configuration MBean. If the "cd" command throws an exception then you can safely assume that the resource/configuration doesn't exists and you can continue creating.


...
### Check for the server
try: 
    cd('/Servers/' + mgdServerName)
    print '===> Server \"' +mgdServerName+'\" already exists'
    print '===> No action was performed'
    exit()
except:
    pass
...

The other approach is to catch the "BeanAlreadyExistsException" while creating the resource and safely exiting the script.


...
### Create the Managed Server
edit()
startEdit()
try:
    create(mgdServerName, resourceType)
    print '===> Created Managed Server - ' + mgdServerName
    pass 
except BeanAlreadyExistsException:
    print '===> Server \"' +mgdServerName+'\" already exists'
    print '===> No action was performed'
    cancelEdit('y')
    exit()
...

But with this approach you are starting an edit session and creating the server to find out it's existence. So you have to cancel the edit session once you find out that the resource that you are creating already exists if not you might get a warning message similar to the following:

You have an edit session open and you will lose all outstanding changes and your edit session will be stopped if you exit. Are you sure you would like to exit? (y/n)

So cancelling the edit session with a responce 'y' will make WLST not to prompt for user response. I shall discuss how to streamline the outputs from WLST and redirect them to an output file or log file in a later post.

WLST-BP-3 Check for the resource or configuration existence before creating them

Do Not Step On Other's Feet [WLST scripting Best Practices (Part-2)]

2009-02-26T10:42:00.000-08:00

This post is a continuation of my previous post - in a series of posts about WLST scripting best practices. When using WLST script for performing configuration changes always check whether someone else is making changes. WebLogic support configuration changes using many methods but not limited to:

Administration Console
Interactive WLST
WLST SCripts
JMX
Ant Scripts
3rd Party Tools

So it is always better to check whether someone else is making changes while you are ready to start a change session. WebLogic Server will allow only one change session at a time no matter which one of the above methods you use for configuration management. Especially environments with multiple administrators the best practice is to have individual logins for each administrator so that you can have more controlled environment. If you are interested in configuration auditing to find out who is responsible for what, see this post.

Use the Configuration Manager to find out information about existing change sessions. You can find out whether someone else had already started a change session, if so who is making changes, are there any unactivated changed, if so what changes are unactivated etc. from the configuration manager. The following example illustrates a code snippet which checks for existing sessions using configuration manager:


...
### Get the Configuration Manager and check for existing session
cfgManager = getConfigManager()
try:
   cfgManager.getChanges()
   print '===> Someone else is making changes'
except: 
   print '===> No one else is making changes'
...

The following example illustrates a code snippet which checks for the number of unactivated changes using configuration manager:


...
### Get the Configuration Manager and check for existing session
cfgManager = getConfigManager()
try:
   cfgManager.getChanges()
   print '===> Someone else is making changes'
   noOfChanges = cfgManager.getUnactivatedChanges().__len__()
   print 'There are ' + noOfChanges + ' unactivated pending changes in the current edit session'
except: 
   print '===> No one else is making changes'
...

The above code snippet may work only if you are the user who is making the changes. The following example illustrates a code snippet which checks and prints the user who is currently making changes using configuration manager:


...
### Get the Configuration Manager and check for existing session
cfgManager = getConfigManager()
try:
   cfgManager.getChanges()
   print '===> User ' + configmanager.getCurrentEditor() + ' is making changes'
except: 
   print '===> No one else is making changes'
...

The following example is a complete script which checks for an existing session and if one doesn't exists then it will create a new managed server by starting a new session. If a session already exists then it will simply display that information and will exit.


from weblogic.management.mbeanservers.edit import NotEditorException

### CreateMgdServer.py
### Define all the requried variable
username = 'braman'
password = 'weblogic'
url = 't3://localhost:7001'
mgdServerName = 'mgdserver1'
resourceType = 'Server'
listenAddress = 'egmgd1'
listenPort = 2001

### Connect to the Administration Server
connect(username, password, url)

### Get the Configuration Manager
cfgManager = getConfigManager()
try:
   cfgManager.getChanges()
   print '===> Currently there is a Session'
   if cfgManager.isEditor() == true:
       ### You are making changes!!!
       print '===> Looks like you started that session'
       print '===> You can check the console for any pending changes'
       print '===> Try rerunning this script after you release or commit the pending changes'
   exit()

except NotEditorException, e:
   if cfgManager.getCurrentEditor() is None:
   ### No session
       pass
   else:
       ### Someone else is making changes
       userWithSession = cfgManager.getCurrentEditor().replace(' ', '')
       print '===> Currently there is a Session'
       print '===> User \"' +userWithSession+'\" is making the changes'
       print '===> Wait until \"' +userWithSession+'\" complete the current session'
       exit()
   pass
except Exception:
   ### Other Errors
   print '===> Error, see log for more info'
   exit()


### Start a change session
edit()
startEdit()

### Create the Managed Server
create(mgdServerName, resourceType)
cd('/Servers/' + mgdServerName)
cmo.setListenPort(listenPort)
cmo.setListenAddress(listenAddress)
print '===> Created Managed Server - ' + mgdServerName

### Activate the changes
save()
activate()

### Disconnect from the Administration Server
disconnect()
exit()

To explain some tricky parts of the above script:

This is line of code is used to import the exception class
from weblogic.management.mbeanservers.edit import NotEditorException

To check whether you are holding on to a session currently you can use the following method on the configuration manager
cfgManager.isEditor()

To get the user who is currently making changes you use the getCurrentEditor method on the configuration manager
cfgManager.getCurrentEditor()

To get rid of all the white spaces you can use a replace method from the string class (this is Jython)
userWithSession = cfgManager.getCurrentEditor().replace(' ', '')

The above example works if you don't have a managed server named egmdg1. But if you already have a managed server in your domain with the same name then the script will fail with the following error:

weblogic.descriptor.BeanAlreadyExistsException: Bean already exists

You can handle that situation in couple of different ways. I shall continue on how to tackle that in my next post.

WLST-BP-2 Check for existing session before you start one

Variable Definitions In The Preamble [WLST scripting Best Practices (Part-1)]

2009-02-25T06:45:00.000-08:00

With WLST becoming popular among WebLogic Administrator, there is an unsaid need to discuss the best practices with respect to WLST scripting. I am being asked to share information about WLST like an introductory/101 post. But I decided to start a series of post which might help WebLogic Administrators with some of the must follow best practices rather than writing some introductory post which might duplicate the documentation. For WLST documentation see here.

The common steps involved in a WLST script that is used to configure WebLogic Server are as follows:

1. Connect to server
2. Navigate to the respective location (MBean)
3. Modify the required properties
4. If more configuration needs to be modified continue Step-2
5. Else disconnect
6. Exit

The first of the series of best practices in authoring a WLST script is to define all the required variables at the beginning before connecting to the server. That way if any modifications must be done in the future it will be as easy as changing the variables defined at the beginning of the script. In the coming posts, I will talk about more of other best practices like writing a reusable WLST script, consuming information from the environment variables, exception handling, defensive scripting, avoiding to hard code critical information like username, password, url etc.

The usual variables are the username, password, url, resource names, attribute values etc. The following is an example of a script that defines all the required values as script variables which can avoid hardcoding and will also facilitate simple way to modify them in the future if required.


#CreateServer.py
#Define all the requried variable
username = 'system'
password = 'weblogic'
url = 't3://egAdm:7001'
serverName = 'mgdserver1'
listenAddress = 'egmgd1'
listenPort = '2001'

#Connect to the Administration Server
connect(username, password, url)

#Start a change session
edit()
startEdit()

#Create the Managed Server
create(serverName, 'Server')
cd('/Servers/' + serverName')
cmo.setListenPort(listenPort)
cmo.setListenAddress(listenAddress)

#Activate the changes
save()
activate()

#Disconnect from the Administration Server
disconnect()
exit()

The above script may not be authored using all the best practices now. But I will eventually build on the same example of creating a new Managed Server in my subsequent posts to address the other best practices as well. My next post will talk about how to check for existing change session before you start one with WLST.

WLST-BP-1 Define all the variables in the preamble

Easy Syntax with WLST

2008-12-17T07:49:00.000-08:00

WLST is a powerful scripting solution for managing and administering WebLogic Server and resources deployed on them. WLST is built on the Java implementation of the scripting language Python called as Jython. All the commands in WLST are implemented as Jython functions and they require a set of parentheses for passing any arguments. Even any commands that do not require any arguments are supposed to be suffixed with parentheses. For example the command "ls" is used to list all the child MBeans and/or attributes of the current MBean you are at.

ls() - lists all the child MBeans and attributes
ls('a') - lists all the attribute names and values only
ls('c') - lists all the child MBeans only

So even if you want to invoke "ls" with no arugments you must use "ls()". This might not be an issue when you are building scripts that you might want to run many times. But while connected to a server and working with WLST in interactive mode, it might get a little frustated to type the parentheses everytime you want to run some simple commands with no arguments. To ease this pain there is a hidden option in WLST which can be used to ease the syntax for WLST commands - easeSyntax().

You can supply the "easeSyntax()" command to ease the syntax but this is not recommended for script mode and especially when using loop constructs. You can also use the regular Jython syntax with parentheses even after you enabled the easy syntax. To turn off the easy syntax mode simply issue the command again "easeSyntax".

Bye Bye parentheses!

How To Encrypt Clear Text Passwords With WebLogic Server

2008-10-20T18:56:00.000-07:00

WebLogic Server encrypts all the plain text passwords stored in its domain configuration XML file(s). This is to prevent access to sensitive information. When passwords are entered using administration console or scripting tools, it will automatically get encrypted before they are stored in the configuration XML files(s).

Prior to WebLogic Server 9.0

If those passwords need to be reset either the configuration tools (Console or scripting tools) can be used which will automatically re-encrypt the passwords or by directly changing the configuration files using a text editor. When files are directly modified using a text editor the passwords will get encrypted during the subsequent restart.

Starting from WebLogic Server 9.0

Using clear text passwords in the configuration files are supported only for Development domain and it will not re-encrypt the passwords. If the domain is a Production domain then you cannot set the passwords in clear text. You have to either use a dedicated command-line utility or WLST to encrypt the clear text passwords. If the server encounters a clear text password when parsing the configuration file(s) while starting in Production Mode, then you will get an error similar to the following:

<Oct 20, 2008 9:05:35 PM EDT> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason: [Management:141266]Parsing Failure in config.xml: java.lang.IllegalArgumentException: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean>

Depending on the configuration the MBean name value of the error message may change. In this case the ServerStartMBean has clear text value for a password property. Either the dedicated Java utility to encrypt clear text values can be used or WLST cant be used to re-encrypt. To run the encrypt utility follow the instructions below:

Change directory to your domain's bin folder (For Eg. cd c:\bea\user_projects\domains\mydomain\bin)
Execute the setDomainEnv script (For Eg. setDomainEnv.cmd)
Execute java weblogic.security.Encrypt which will prompt for the password and will print the encrypted value in stdout.

The following are some sample output from running the utility

C:\bea\user_projects\domains\mydomain>java weblogic.security.Encrypt
Password:
{3DES}9HWsf87pJTw=

You should execute this utility from the domain folder as it requires the domain's password salt file (SerializedSystemIni.dat) for encrypting the clear text string. You can also pass the clear text string as an argument

C:\bea\user_projects\domains\mydomain>java weblogic.security.Encrypt testpwd
{3DES}9HWsf87pJTw=

You can also use WLST to encrypt clear text strings as below:

C:\bea\user_projects\domains\mydomain>java weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> es = encrypt('testpwd')
wls:/offline> print es
{3DES}9HWsf87pJTw=
wls:/offline>

When running WLST from a location different than the domain folder you can pass in an argument to specify the domain directory. Once you have the encrypted value, the configuration files can be modified to include this encrypte value instead of clear text passwords. These features will make your domain to operate when resetting the encrypted passwords on a Production domain's configuration XML files. These methods not only can be used to encrypt configuration XML (config.xml) but also the JDBC or JMS descriptor XML files.

Encrypt the credentials when running WLST in interactive or script mode

2008-09-24T22:26:00.000-07:00

One of the common request I hear from administrators is that they want to get away from providing user name and password in plain text when using WLST. WebLogic Server provides a way to encrypt the credentials for server start up. You can create a password file "boot.properties" (called as Boot Identity File) with plain text credentials in a folder named security under the server root directory. This file will be automatically detected during the server start up and the server will encrypt the information in this file for subsequent use. Until WebLogic Server 9.x this file should be placed under the DOMAIN folder. So servers sharing the same file system share the same boot identity file and cannot be configured to use different files.

This boot identity file can also be used by WLST only when started from the domain folder. This is mainly because the domain's password key (SerializedSystemIni.dat) is used to encrypt this file. If you are using WLST from a different location or from a remote machine to connect to the server or if you want to run WLST script you can use a different technique. You can use WLST to generate a User Configuration file which will have encrypted user name and password using storeUserConfig() command. A key file that will be used to encrypt the data will also get generated along with the user config file. The key file is important as it is required to decrypt the values back from the user config file. This is an online WLST command. So you should be connected to a running WebLogic Server or a Node Manager to issue this command.

When you use this command with no arguments the user configuration file for the current user will be generated within the current OS user's home folder.

wls:/testdomain/serverConfig>storeUserConfig()

You can also specify the location and name for the key file and the userconfig file if you want them to be created elsewhere.

wls:/testdomain/serverConfig>storeUserConfig('/usr/home/user1/configfile.secure', '/usr/home/user1/keyfile.secure')

If the files are stored with the default name (osusername-WebLogicConfig.properties & osusername-WebLogicKey.properties) you can simply connect without specifying the username and password in the connect() command.

wls:/offline> connect(url='t3://host:port')

If the files are stored in a different location or with a different name, then they can be passed as an argument to the connect() command.

wls:/offline> connect(userConfigFile='/usr/home/user1/configfile.secure', userKeyFile='/usr/home/user1/keyfile.secure', url='t3://host:port')

No more plain text user name and password in when using WLST. Have a safe and secure scripting!

New differences between development domain and production domain in 10gR3

2008-09-05T08:00:00.000-07:00

During domain creation you can specify the start up mode for your domain either as development mode of production mode. Most of you who work with WebLogic Server for the past few releases should know that there are few differences between a development domain and production domain. (http://e-docs.bea.com/common/docs103/confgwiz/newdom.html#wp1097267)

Development Mode
The default JDK for development domain is Sun Hotspot
You can use the demo certificates for SSL
Auto deployment is enabled
Server instances rotate their log files on startup
Admin Server uses an automatically created boot.properties during startup
The default maximum capacity for JDBC Datasource is 15
The debugFlag which is used to start the WebLogic Workshop Debugger is enabled

Production Mode
The default JDK for production domain is JRockit
If you use the demo certificates for SSL a warning is displayed
Auto deployment is disabled
Server instances rotate their log files when it reaches 5MB
Admin Server prompts for username and password during startup
The default maximum capacity for JDBC Datasource is 25
The debugFlag which is used to start the WebLogic Workshop Debugger is disabled

In addition to the above WebLogic Server 10gR3 adds a few more default configurations depending on whether the domain is started in development or production mode.

The domain configuration locking feature is only enabled for production domains - http://e-docs.bea.com/wls/docs103/notes/new.html#wp1088380
Confirmation prompts for operations are enabled only for production domains - http://e-docs.bea.com/wls/docs103/notes/new.html#wp1088380
Fast Track deployments are not recommended for production domains - http://e-docs.bea.com/wls/docs103/quickstart/quick_start.html

Add your own commands to WLST

2008-08-28T20:07:00.000-07:00

Do you want to add your own commands to the already rich set of WLST commands?

You can do so by building your own *.py file and adding them to WL_HOME/common/wlst/lib folder. Any *.py file added to this folder will be automatically compiled and imported by WLST when started on that machine. So the custom commands built as definitions inside these modules can be used by calling them on the respective module names.

If you have a TestLib.py stored under WL_HOME/common/wlst/lib folder:


TestLib.py
----------
def testCmd():
    print 'This is a test command'

And if there is a definition called testCmd() defined in it then you can call it as follows:

wls:/offline>TestLib.testCmd()

What you waiting for? Go and add you command to WLST now.

Finally Embedded LDAP dependency is gone!

2008-08-25T17:31:00.000-07:00

WebLogic Security Realm is a collection of configuration that protects a WebLogic Domain, its application and resources. Until WebLogic Server 10.3 the default store (Security Provider Database) used for security configuration such as users, groups, roles, policies etc. is the Embedded LDAP Server. But many customers want to externalize these information from WebLogic's Embedded LDAP Server. Different options are available only to externalize the authentication information to an external LDAP server, RDBMS etc. But still other information like authorization information, role mapping etc. stayed within the Embedded LDAP server.

With WebLogic Server 10.3 now you can choose to use an external RDBMS as a security provider database to store all security provider information. This removes the dependency of Embedded LDAP server. The other options is to build custom security providers which can use properties file as security provider database. Now you can build a WebLogic domain with no dependency to bundled Embedded LDAP server.

See http://edocs.bea.com/wls/docs103/secintro/realm_chap.html#wp1033627 for more info on how to configure a RDBMS based security provider database. One of the key thing to note is that the tables should be manually created using the appropriate *.sql file available from BEA_HOME/wlserver_10.3/server/lib directory. The domain's security provider database can be based on RDBMS when you create the domain using Configuration Wizard or later using Administration Console. Also the default Authentication Provider that comes with the default security realm - myrealm is Embedded LDAP based. So if you want to completely avoid the dependency with Embedded LDAP server then after the domain is created you have to create an Authentication provider that will use an external user repository (RDBMS, external LDAP etc.)

You can configure a domain to use RDBMS based security provider database during the domain creation using Domain Configuration Wizard.

But make sure that the tables are created before starting the Administration server according to the *.sql files provided with WebLogic installation.

If you created the domain with the default configuration (Embedded LDAP server as the security provider database) then you can change the domain configuration later to use RDBMS based security provider database.

Will meet you all with more exciting new features from Oracle WebLogic Server 10gR3!

New Flexible WebLogic 10gR3 Installer

2008-08-15T20:58:00.000-07:00

Before installing WebLogic Server 10.3 you can now customize and select various components you want to install. I already wrote about this in my other post on WebLogic Server 10.3 Tech Preview. But here is the updated screens shot from the GA release which is now called as Oracle WebLogic Server 10gR3.

The new cool feature that customers will really benefit from is the information about the approximate install size of these different products and components so that you can reduce your server installation footprint.

Also now you can choose which JVM you need to install from the default JVMs that Oracle ships with WebLogic Server 10gR3 (Hotspot and JRockit). In addition if you already have local JDK you can select that during installation.

Along the same line you can choose to install Eclipse or use an existing Eclipse installation for Workshop.

Free Workshop Eclipse Plug-in

2008-08-15T20:35:00.000-07:00

In addition to the standard IDE - JDeveloper, Oracle is also providing Eclipse tools (plug-ins) for WebLogic Server 10gR3. Oracle made it really simple for developers by making them as a single install. Also the Workshop Eclipse Plug-ins are now free - Yes! Oracle removed the licensing on them with the new WebLogic Server 10gR3.

Go here to download Workshop for WebLogic 10gR3 - http://www.oracle.com/technology/software/products/ias/bea_main.html#devtools
Workshop is now a one-stop-shop for building Java EE components and Web Service components for not just WebLogic Server but for a variety of different application servers. Yes, Workshop for WebLogic will be freely available on all supported platforms, including websphere, weblogic, tomcat, jboss, jetty and resin. But Adobe Flex Builder bundle has been removed from the Workshop for WebLogic bundle.

Now Workshop can be used for building Struts, Spring, Tiles, Hibernate, JPA and many more Java components to run on a variety of different web containers. Try now!

Oracle WebLogic Server !!!

2008-07-28T16:22:00.001-07:00

If you are following the news BEA is now Oracle and so Oracle WebLogic Server. Go the Oracle website and click on the Application Server area, you will find out that WebLog ic found its spot there. Click to go there - http://www.oracle.com/appserver/index.html.

One of the key information you find on the above website is a 90 minute web-cast that explains Oracle's Middleware Strategy or go directly here - http://www.oracle.com/webapps/events/EventsDetail.jsp?p_eventId=81641. Oracle President, Charles Phillip and SVP, Thomas Kurian talks about the companies strategy in general and the future of Fusion Middleware products and BEA products. If you are interested in BEA products OR in Oracle middleware products this presentation will be worth you time.

I will soon come up more more information about some exciting features of WebLogic Server 10.3.

WebLogic Server 10.3 Tech Preview

2008-06-25T14:20:00.000-07:00

I am so excited about the new features of WebLogic Server 10.3 which is in Tech Preview right now. So I thought I would share some of the cool features coming...

In development Admin Console is deployed on demand the very first time someone access it. This will save memory and will speed up the development servers startup.
Admin Console is now internally tuned for better response time.
Light Weight Installer- Fine grained installer to reduce the footprint of the installation.

Light Weight Runtime - If you are not using EJB, JMS, JCA you can disable those services to start WLS in a light weight mode.
On Demand Internal Application Deployment - UDDI Explorer, Console, WS Test Client and their runtime can be be deployed on demand. This will also reduce the server's footprint when you are not using them.
WLS 10.3 is shipping with JDK 6.
Web 2.0 is now supported for building rich internet applications.
Support for C# client with JMS will let .NET applications directly access JMS in WLS 10.3

and much more...

See http://e-docs.bea.com/wls/essex/TechPreview/pdf/feature_overview.pdf for more info.

Try WLS 10.3 TP

Audit WebLogic Server domain for configuration changes

2008-04-18T06:12:00.000-07:00

In a typical WebLogic shop with more than one administrator managing the WebLogic domain(s) there is possibility that these admins can make changes without one others knowledge (at different times). To have an audit of all the configuration changes the "Configuration Audit Type" of the domain should be set. You can create the audit log entries in the administration server's server log by setting it to "Change Log" or "Change Audit" will forward it to the security audit log or "Change Log and Audit" will send it to both these logs.

See this section of edocs for more info on how to change this value.

I believe this is one of the hidden secrets in WLS. You can also audit any changes that were made and not activated but released in the audit log entries. Another main use of this feature could be to watch the security changes like who is adding new users, groups etc. The actual security audit provider only audit events like AUTHENTICATION, USERLOCKOUT etc.

Here are some sample configuration audit entries when I create a user called 'test' and added the user to the 'Administrator' group (other entries from the log file are removed for clarity):

####<Apr 1, 2008 5:12:07 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207084327610> <BEA-159907>
<USER weblogic INVOKED ON Security:Name=myrealmDefaultAuthenticator METHOD listMemberGroups PARAMS test>

####<Apr 1, 2008 5:12:07 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207084327626> <BEA-159907>
<USER weblogic INVOKED ON Security:Name=myrealmDefaultAuthenticator METHOD addMemberToGroup PARAMS Administrators; test>

####<Apr 1, 2008 4:59:48 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207083588603><BEA-159907>
<USER weblogic INVOKED ON Security:Name=myealmDefaultAuthenticator METHOD createUser PARAMS test; ****; >

As WebLogic doesn't have the concept of super admin, all the administrators are treated the same. So when you have more than one administrative user managing a domain, the configuration audit feature will help you find out which admin did what.

Would you like to have a view of WebLogic Server instances from a control tower ?!

2008-03-17T11:54:00.000-07:00

If you have enterprise-wide management systems in place and are looking a way to integrate WebLogic Server instances then WebLogic Server SNMP is your option. You can use Simple Network Management Protocol (SNMP) to provide monitoring data from your WebLogic Server instances to your enterprise-wide management systems.

SNMP set of standards provides a framework for the definition of management information along with a protocol for the exchange of that information. The SNMP model assumes the existence of managers and agents. A manager is a software module responsible for managing part or all of the configuration on behalf of network management applications and users. An agent is a software module in a managed device responsible for maintaining local management information and delivering that information to a manager via SNMP. A management information exchange can be initiated by the manager (via polling) or by the agent (via a trap). Agents function as collection devices that gather and send data about the managed resource in response to a request from a manager.

WebLogic supports SNMP for a long time starting from version 5.1. WebLogic SNMP enables you to move towards a single management console and thus provide integrated systems management of WebLogic Server based applications. Also WebLogic SNMP enables you to connect WebLogic Server to popular management systems such as HP OpenView, IBM Tivoli, MRTG, and Sun SunNet Manager. This makes managing WebLogic Server more effective by providing a whole-system perspective instead of piecemeal solutions.

In WebLogic Server Version 10.x SNMP implementation went through a lot of changes. Some of the important changes are:

WebLogic Server SNMP implementation now supports SNMPv3 with SNMPv1 and SNMPv2. SNMPv3 provides additional security compared to prior versions.

Previously only one SNMP agent per domain which runs on the Administration Server now you can create multiple agents on different servers. This removes the dependency with Administration Servers.

Now custome MBeans can be monitored using SNMP in addition to standard WLS MBeans.

The old command-line utilities are not deprecated and a new command-line utility is introduced - weblogic.diagnostics.snmp.cmdline.Manager

SNMP agents in WLS can now use TCP port in addition to UDP Port which was the only option in the previous versions. And many of the configuration changes in SNMP are now dynamic which doesn't require start.

For more information read the edocs - http://edocs.bea.com/wls/docs100/snmpman/snmpagent.html

With more and more system and server administrator coming to the paradigm of administering application servers and enterprise applications, this will provide them a way to integrate WebLogic with enterprise level monitoring solutions.

Does your WLS File Store grow in size?

2007-12-18T12:02:00.000-08:00

JMS Server in WLS only removes the messages that are expired once in every expiration scan interval (A JMS Server level config). The destination may have expired message sitting in them if the expiration scan interval property is set to a high value. For ex. 1800 will cause the JMS Server to scan for expired messages once in 30 mins. Still applications cannot receive the expired messages - they will be sitting in the destination. But it doesn’t automatically do any compaction per se. So the file size of the WLS File Store may keep increasing. This might cause slow startup of the server.

You can perform manual offline compaction in the following ways:

There is a Java command-line utility that can do this trick "weblogic.store.Admin". See Edocs for more info.

A WLST command called "compactstore" can also do the same trick. See Edocs for more info.

Note that this compaction is supported only for WLS File Stores and not for JDBC Stores as they don't suffer with the same issue of compaction.

The Java command-line utility "weblogic.store.Admin can also be used to dump the contents of a store into an XML file for troubleshooting purpose.

Play Hide & Seek with Administration Console

2007-11-09T09:04:00.000-08:00

Everyone who work with WLS knows that the Administration Console is the light weight web based UI provided by BEA for configuring, monitoring and managing a WLS domain. Automation and Scripting can be done in many ways. See this post for more info.

Exposing the console in your production environment might be security issue. In those cases you can either disable the console or hide it. Needless to say if you disable the console then your only option is to depend on command-line and scripting tools for any other administration activity or to even enable the console back. But hiding will provide a level or security.

To disable the console:

In the admin console navigate to --> General --> Advanced Options --> Console Enabled. De-select that option to disable console (restart required).

To hide the cosole:

Enable the administration port on the domain so that console can only be accessed on the 2-way secured admin port. This will force all the clients to have valid certificate installed in their client (browser) to access the console.
In the admin console navigate to --> General --> Advanced Options --> Console Context Path and change the context-path of the console to something unique and only known to the administrators.

All is fine. But one of the common question is how can I enable the console once I disable them. Like I said earlier you have to rely on the scripting tool to enable the admin console once it is disabled. You either perform this action interactively or by running a WLST script. See the following sample WLST script for more info:

connect("username","password")
edit()
startEdit()
cmo.setConsoleEnabled(true)
save()
activate()
disconnect()
exit()

You have to restart the administration server to get the console back. Have fun playing hide and seek with the console!

In WLS 10.3 with the Light Weight Server Installer, you can choose not to install WLS Admin Console when you install WLS. Along with the other installation options, this provides a way to reduce the server installation footprint and runtime memory footprint. Can't wait to play with WLS 10.3, you can now download the Tech Preview at http://commerce.bea.com/showproduct.jsp?family=WLS&major=10.3Tech&minor=-1
(as of Nov 9, 2007 WLS 10.3 is only a Tech Preview Release). I will write more on the WLS 10.3 release which is build on BEA microService Architecture (mSA) soon. Read more about BEA mSA here http://www.bea.com/framework.jsp?CNT=msa.jsp&FP=/content/.

Is my Administration Server single point of failure?

2007-11-02T05:35:00.000-07:00

The answer is No and Yes. Read on for more specific info....

WebLogic domain consists of Servers, Machines, Clusters, Applications and Configurations related to them. Administration sever is the controlling instance for the domain. It is the keeper of all the configuration. Ideally you don't want to host (target) any application or service that clients would access on the admin instance. Managed server(s) or cluster(s) are meant to host such applications and services that clients would access (servers other than admin server in a domain are called as managed servers).

Having said that, if an admin instance fails during the middle of the day what happens to my domain? It is the controlling instance so will it halt my domain? The answer is NO. Admin server will provide all the configurations to each managed server and they will be cached locally. There are limited dependency between the servers during runtime. So an admin server failure will not affect the running managed server(s) or cluster of managed server(s).

Alright, what about the "Yes" part of the above answer?! There are few services you will lose when an admin instance is not available. You cannot introduce any new configuration or change any existing configuration in the domain. Examples are: you cannot deploy new applications, you cannot change the JNDI name of a JMS destination hosted on one or more servers etc. You will also lose the domain log entries in the Domain Log file maintained by the administration server. Still you can use the Server Log maintained on each managed server for auditing or troubleshooting purpose. Also lastly the managed server(s) in the absence of admin server can only be started or restarted in Independence Mode (using the previously cached local configuration information).

You are not expected to introduce new configuration or change any configuration on the fly in your production setup so losing the ability to do this will have literally no or little impact.
You can use server log file entries for auditing and troubleshooting purposes.
The managed server can be restarted or started if required during the absence of admin server using Independence Mode (which is a default setup now in WLS 10.x - no extra configuration required).

Admin server (for that matter any server in the domain) can be configured to automatically get restarted in case of failures using a feature called - whole server migration. I will talk about this in a later discussion.

So now you know why I said "No" and "Yes"! huh!

Managed Server Independence Mode

2007-09-18T16:24:00.000-07:00

Starting from version 7 WebLogic managed servers can be started in the absence of an administration server. The feature that will enable a managed server to come up in the absence of administration server (MSI mode) is enabled by default. But some of the files required for MSI mode are only sent to the managed server only when another option (MSI file replication enabled) is ON.

This feature is same in version 8 except that the config.xml being copied and cached in the managed server is stored as msi-config.xml.

In version 9 the feature is still the same except that the complete config directory that contains the configuration file is copied by default to the managed servers. But some other files like the security (*.dat) file is not copied until the MSI file replication enabled option is ON.

Version 10 alleviate all the pains by making MSI mode and MSI file replication as a default option. So out of the box a managed server is enabled to run in independence mode. And all the files required to start a managed server by itself (/config dir and *.dat file) will be automatically copied to the managed server during startup and will be synced (automatically) with the master copy (in Admin Server).

Scripting & Automation

2007-07-17T07:20:00.000-07:00

Administrators always love scripting solutions. Because it is reusable and it can be executed by anyone. However it is not so easy to learn any scripting solution per se. A good example is UNIX shell scripting, where you must know the commands to build a scripting solution. But once you get ramped up it very simple to build a script.

WebLogic Server(WLS) provides many ways for an administrator to script different configuration and management tasks. Needless to say if the administrators are also Java developers they can use the management API used by WLS (JMX) for building such scripting solutions. If you are not a developer you don't have to panic you have other alternates that you can use.

If you are in WLS 8.1 or lower you can use anyone of the following solutions for scripting

Weblogic.Admin utility
WebLogic Ant tasks
WebLogic Scripting Tool (WLST)
Thirt-party solutions (WLShell etc.)

If you are in WLS 9.x or higher you still have all the above options but the Weblogic.Admin utility is deprecated and WLST is the recommended solution. But Weblogic.Admin is still for backward compatibility reasons.

But one of the challenge is for the administrator to ramp up on such scripting solutions provided by different vendors. WLS 10 solve that problem by providing a management plug-in to the light weight web-based UI (Administration Console) - WLST Script Generator. Using this you can record all your console interactions (Configurations) into a reusable WLST Script. It is like a little macro recorder that will solve your problem or ramping up on WLST if you are new to it.

The Administration Console does not record WLST commands for the following:

Changes to the security data that is maintained by a security provider. For example, it doesn't record the commands if you add or remove users.
Changes that are made to the application using console which will end up in deployment plans.
Runtime operations that you perform on Control or Monitoring pages, such as starting servers, suspending a JDBC Connection Pool etc.

To read more about WLST go here.
To read more about recording WLST Scripts go here.

I shall share more tips on WLST in my later posts.

Whats the deal with SNMPv1, v2 and v3

2007-06-20T07:58:00.000-07:00

Here are some of the questions I got from someone few days ago. See my answers inline.

Q: The WLS SNMP agent supports 2 trap versions: V1, V2 and V3. What's the difference between these 3 versions?

[A] SNMPv1 and SNMPv2 are the two version of SNMP implementation. Until WLS 9.x only SNMPv1 and SNMPv2 are supported. Now we have SNMPv3 implemented in WLS 10. Both SNMPv1 and SNMPv2 use community strings to authenticate the packets as SNMP uses UDP (a broadcast protocol). The community string is sent in plain-text in every single SNMPv1 or SNMPv2 packet and the agent uses it to decide to process the packet or discard it. The main difference between SNMPv1 and SNMPv2 is that SNMPv2 added a few more packet types like the GETBULK PDU which enable you to request a large number of GET or GETNEXT in one packet.

SNMPv3 was designed to address the weak V1/V2 security. SNMPv3 is based on SNMPv2 (same packet types), but the main difference is that it is a lot more secure. It does not use community strings but users with passwords and SNMPv3 packets can be authenticated. For more info about SNMP Security from our edocs Security for SNMP.

Q: The SNMP architecture diagram demonstrates that you can poll MBean attribute values from Managed Servers. However, the SNMP commands such as SNMPWALK and SNMPGET don't allow you to specify the addresses and/or names of the Managed Servers that you'd like to poll. How can I tell which Managed Server(s) to poll?

[A] SNMP architecture until WLS 9.x doesn’t allow you to create multiple agents in a WLS domain. The agent implementation was only available in the administration server of the domain. The managed servers will be communicated by the agent when a SNMP manager talks to the SNMP agent running on the administration server. So if you want to get MBean attribute value from a managed server in a domain you must differentiate it using the OID. So you will still point your SNMPWALK and SNMPGET to the admin host and agent port. If you are not sure about the complete OIDs of the managed objects on the WebLogic managed servers you can use snmpwalk to get the root OID of the managed object (or) the attribute by suffixing the managed server's name to the community prefix.

A common (and tricky) security question

2007-06-15T21:48:00.000-07:00

One common question people always ask me is "If I forget my administrator password how can I reset it". It was simple during WebLogic Server 6.1 days where the password was stored in a plain text file - filerealm.properties. When they released version 7.0 of WebLogic Server(WLS), the security architecture went through a complete overhaul. They introduced a file based Embedded LDAP server for storing security related information in the domain.

First there are few recommendations that I want to share with you:

Create a backup admin user and keep it safe so that you can use that admin user in such disaster scenario. Make sure you keep that info in a safe place.
Take periodical back ups of your domain's embedded LDAP directory on the admin server machine(/Servers/AdminServer/data/ldap/).
Take periodical back ups of the individual providers in you real using WebLogic Server security import/export feature. (For more info see Export data from a security provider from edocs)

Following are some of the ways in which you can answer the above question:

If you are in development, one option is you can simply recreate the domain from the existing domain by creating a Domain Template using Domain Template Builder. That way you don't loose any configuration that you did in the original domain but any security changes you made will be lost.

If you have already created User Config file set for the admin user, run a JMX Script to change the admin user password using that User Config file set. Obviously you might want to recreate the User Config file set after you change the password. If you have no User Config file set created for the admin user then follow one of the following steps.

Delete the ldap sub-directory under the adminserver folder and restart the adminserver(Obiviously make a backup before you delete). It will automatically rebuild the ldap from the *.ldift files in the domain directory (created when the domain was created Ex. DefaultAuthenticatorInit.ldift). This will work if you changed the admin password after creating the domain and you forgot/loose the new password but still remember the old password which you created when you created the domain (Strange use case ! huh). When using this method you will loose all the existing users and groups in the ldap so you might want to export the users and groups before you delete the ldap and import them back later. But this can be performed only if you still have access to the console or some pre written backup scripts which are using encrypted username and password in the form of user config file.

If you don't remember the Adminstrator password at all (Original or Changed) and if you are ready to loose all the user and groups (if not backed up using export feature) in the existing ldap then delete the ldap sub-directory under the adminserver folder (Don't forget to create a backup). Edit the file 'DefaultAuthenticatorInit.ldift' in a text editor and locate the line 'dn: uid=adminusername,ou=people,ou=@realm@, dc=@domain@' (Obiviously make a backup before you edit). Edit the value for the attribute 'userpassword' to a known plain text value. Restart the admin server using the new credentials. The domain will recreate the ldap with the new admin username and password. If you have already exported the old users and groups import them back.

What if you haven't backed up any users or groups and you also don't want to loose them. But still you want to recover the lost administration user password. In such scenario to recover the administrator password in a WebLogic domain, provided the default Admin role is not modified/removed perform the following:

At the command line, change directory to the domain and run the setEnv script to set the PATH and CLASSPATH.

Create a new DefaultAuthenticatorInit.ldift: run java weblogic.security.utils.AdminAccount tempadminusername temppassword ./

Remove the initialized status file, DefaultAuthenticatormyrealmInit.initialized from the Domain/AdminServer/ldap subdirectory.

Restart the server, using the new user identity.

To change the old admin user identity, log into the admin console or JMX Scripts. (Optional)

Delete and recreate the domain (Yuck!). I dont think you would ever end up doing this unless you change the default Admin role or his permissions. This is highly unlikely situation.

To be or not to be technical

2007-06-07T10:53:00.000-07:00

I was thinking to start a technical blog for a long time and I kept on deferring it. By the way who am I and why am I starting this blog?!

My name is Balamurali Kothandarman and I go by the name of "Bala". I am a Delivery Technologist Sr. working with BEA Education Services in USA. My primary job function is to deliver training to our customers in various Technologies and Products. I see a lot of customers every week in my trainings. Many times I receive a follow up question from somone who took a training with me. The question may either be from the course material we use for the training or from a general product and technology stand point. Either way I see a lot of repeating questions. So I decided to do this blogging where not only customer who attend our trainings but also other who are interested can participate and collaborate in this blog regarding WebLogic Server and realated technologies.

I also have an oppurtunity to do blogging @ http://dev2dev.bea.com which is pretty good technical website from BEA. But I want to keep my blog more unofficial so here I am.

Feel free to collaborate or ask your questions regarding BEA products or technologies. I shall address them to the best of my knowledge. If I can't address a question directly, I shall get help from my co-workers who are an excellent team.