Archive for October, 2005

WLST – BEAWorld session – part 3

Monday, October 17th, 2005

Continuing with the demo, this will be the final part of the demo.
Now we have a running domain that has an Administration server, two managed servers that belong to a Cluster. For the final part of my demo I used a script that deployed a simple web application to the cluster using the ‘deploy’ command. WLS 9.0 implements the JSR88 API’s for all deployments and WLST surfaces all the deployment functionality using these API’s. The script is shown below.

from java.lang import Runtime
print “Deploying demo application”
deploy(“demo”, “d:/bea/apps”, “mycluster”)
print “Done deploying to cluster”
Runtime.getRuntime().exec(“rundll32 url.dll,FileProtocolHandler http://localhost:8001/beaworld”)

In the script I used the class java.lang.Runtime to start a browser that points to the web app that I just deployed. This demonstrates one of the most useful features of Jython that is able to seemlessly invoke on any Java object. You can also create/modify deployment plans via WLST. If you are not familiar with what a deployment plan is, it is an XML document that resides outside of an application archive and configures an application for deployment. A deployment plan works by setting deployment property values that would normally be defined in an application’s WebLogic Server deployment descriptors, or by overriding property values that are already defined in a WebLogic Server deployment descriptor. For more information on deployment plan’s check out BEA edocs. For the demo I re-deployed the webapp with a deployment plan that overrides the web app’s context root from ‘beaworld’ to ‘wlst’. Before redeploying the application here’s the script that you can use to create a plan and override the context root.

# This will load the application and return a plan object
myplan=loadApplication(“d:/bea/apps”)
# create a Variable
myplan.createVariable(“croot”,”wlst”)
# assign the variable to the module descriptor
cc=myplan.createVA(“croot”,”apps”,”WEB-INF/weblogic.xml”)
# set the xpath
cc.setXpath(“/weblogic-web-app/context-root”)
# save the plan
myplan.save()

and the redeploy script is shown below.

print “Re-Deploying demo application with a Plan”
redeploy(“demo”, planPath=”d:/bea/plan.xml”)
print “Done re-deploying to cluster with plan”
Runtime.getRuntime().exec(“rundll32 url.dll,FileProtocolHandler http://localhost:8001/beaworld”)

The plan.xml is shown below.

<deployment-plan xmlns=”http://www.bea.com/ns/weblogic/90″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
···<application-name>apps</application-name>
······<variable-definition>
·········<variable>
············<name>croot</name>
············<value>wlst</value>
·········</variable>
······</variable-definition>
······<module-override>
·········<module-name>apps</module-name>
·········<module-type>war</module-type>
·········<module-descriptor external=”false”>
············<root-element>weblogic-web-app</root-element>
············<uri>WEB-INF/weblogic.xml</uri>
············<variable-assignment>
···············<name>croot</name>
···············<xpath>/weblogic-web-app/context-root</xpath>
············</variable-assignment>
·········</module-descriptor>
·········<module-descriptor external=”false”>
············<root-element>web-app</root-element>
············<uri>WEB-INF/web.xml</uri>
·········</module-descriptor>
······</module-override>
···<config-root xsi:nil=”true”></config-root>
</deployment-plan></font>

This is the end of the demo. You can also get more information on all the sessions that are presented at BEAWorld here.

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

WLST – BEAWorld session – part 2

Monday, October 10th, 2005

Continuing with the demo …
After connecting to the Administration server, I ran a script that navigated me to the edit tree. Started an edit session with the server, configured servers, a Cluster and started the cluster. Lets take a look at the script.

# start the edit session, configure servers, cluster and start the cluster
print “configuring servers and cluster”
edit()
startEdit()
print cmo
svr1 = cmo.createServer(“ms1″)
svr2 = cmo.createServer(“ms2″)
clus = cmo.createCluster(“mycluster”)
svr1.setListenPort(8001)
svr2.setListenPort(9001)
svr1.setCluster(clus)
svr2.setCluster(clus)
save()
activate()
print “Done configuring servers and cluster”
print “start the cluster”
start(“mycluster”,”Cluster”)
print “Done starting the Cluster”

There is a global variable in WLST called ‘cmo‘ that stands for ‘Current Managed Object‘. This variable is always set to the MBean proxy object that the user navigated to. Since the root of edit tree/drive is DomainMBean, the cmo is set to the DomainMBean proxy. One of the best features of Jython or in fact any Java scripting tool I like the most is to be able to invoke any of the public methods on Java objects in a script. You can declare variables on the fly and assign java objects to these variables. In the script shown above I invoked the method ‘createServer‘ on DomainMBean’s proxy (cmo) and assigned the return value (which is the ServerMBean) to the variable ‘svr1‘. Later I invoked the method ‘setListenPort‘ on the ServerMBean Proxy stored in the variable ‘svr1‘. You can also verify all you changes with the ‘showChanges‘ command. Once you do a save(), you will notice that the changes are written to the DOMAIN_DIR/pending directory and once you do an activate the changes are applied to the running server and the files in the pending directory are removed. After activating my changes with the command ‘activate‘, I started the Cluster. Under the covers WLST invokes the Administration Server which inturn sends the command to start the Servers to Node Manager. Node Manager starts the servers and monitors the state of these servers.
···For the demo I chose to start a Cluster but I was little paranoid because to start a Cluster you will need a network connection to your machine. If in case I did not have a network connection I thought I would just start the servers without a cluster with the backup script as shown below.

# start the edit session, configure serversand start the servers
print “configuring servers “
edit()
startEdit()
print cmo
svr1 = cmo.createServer(“ms1″)
svr2 = cmo.createServer(“ms2″)
svr1.setListenPort(8001)
svr2.setListenPort(9001)
save()
activate()
print “Done configuring servers”
print “start the servers”
start(“ms1″, block=”false”)
start(“ms2″)
print “Done starting the servers”

In my script I had start(‘ms1′, block=’false’) which will let the script to execute the next command after that without blocking. Here’s the WLST console output after running the script.

wls:/mydomain/serverConfig> execfile(“d:/bea/cs.py”)
Already Connected!
configuring servers and cluster

Location changed to edit tree. This is a writable tree
with DomainMBean as the root. To make changes you will
need to start an edit session via startEdit().
For more help, use help(‘edit’)

Starting an edit session …
Started edit session, please be sure to save and activate your
changes once you are done.
[MBeanServerInvocationHandler]com.bea:Name=mydomain,Type=Domain
Saving all your changes …
Saved all your changes successfully.
Activating all your changes, this may take a while …
The edit lock associated with this edit session is released
once the activation is completed.
Activation completed
Done configuring servers and cluster
start the cluster

Starting the following servers in Cluster, mycluster: ms2,ms1
……………………………………………………………………………………
All servers in the cluster mycluster are started successfully.
Done starting the Cluster
wls:/mydomain/edit>

Also, if you are in the interactive mode when you start an edit session, you will notice that the prompt contains a ‘!’ (wls:/mydomain/edit !>) indicating an edit session is in progress. As soon as you activate or stop your edit session the ‘!’ is gone from the prompt.

I will continue the demo in my next blog entry.

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

WLST – BEAWorld session – part 1

Monday, October 3rd, 2005

In BEAWorld this year I had a session on New and Enhanced WebLogic Scripting Tool with the tag line ‘Automate the mundane and slay the difficult’. Inspite of being the last session for the whole event I was impressed with the turn out. Before diving deep into my presentation I did a WLST familiarity check and was pleasantly surprised by the number of users in the audience who raised their hands. The familiarity is majorly due to the fact that we released WLST on dev2dev that works for WLS 7.0 and 8.1 (all service packs). BEA very well understands that many of its major customers do not prefer using tools that are not supported. Hence BEA recently announced support for WLST 7.0 and 8.1. So now users can grab the tool from dev2dev and start using it. If you find any problems you can even file a support case and we will resolve the issue.
···As part of my presentation I have demo’ed some new features in WLST that are available OOTB in 9.0 and promised the audience that I will make the demo scripts available via my Blog. The demo included how one could start from scratch and create a full blown domain consisting of servers in a cluster all via few or one single simple WLST script(s). The demo started of with a simple script that loaded a default template that ships with a typical WLS 9.0 installation. The script sets the administration username and password, sets the administration server name to ‘myserver’ and writes the domain to a directory. Here’s the script that is used to setup the default domain.

# Read the default template that comes with WLS installation
print “Read the default domain”
readTemplate(“d:/bea/load47/weblogic90/common/templates/domains/wls.jar”)
# set the password for default administration user
cd(“Security/base_domain/User/weblogic”)
cmo.setUserPassword(“weblogic”)
setOption(‘OverwriteDomain’, “true”)
cd(“/”)
cd(“Servers/AdminServer”)
cmo.setName(“myserver”)
writeDomain(“d:/bea/mydomain”)
print “Done creating and writing the domain”
closeTemplate()

Lets explore how you can enhance this script to do more. We will configure couple of managed servers, create a cluster and add these managed servers to this cluster. In my demo this is exactly what I did after starting the server and while connected to the server. Here we will do all this even before starting the administration server. The script will look as shown below.

# Read the default template that comes with WLS installation
print “Read the default domain”
readTemplate(“d:/bea/load47/weblogic90/common/templates/domains/wls.jar”)
# set the password for default administration user
cd(“Security/base_domain/User/weblogic”)
cmo.setUserPassword(“weblogic”)
setOption(‘OverwriteDomain’, “true”)
cd(“/”)
cd(“Servers/AdminServer”)
cmo.setName(“myserver”)
cd(“/”)
create(“ms1″,”Server”)
create(“ms2″,”Server”)
create(“mycluster”,”Cluster”)
cd(“Servers/ms1″)
cmo.setListenPort(8001)
cd(“/”)
cd(“Servers/ms2″)
cmo.setListenPort(9001)
assign(“Server”, “ms1,ms2″, “Cluster”, “mycluster”)
writeDomain(“d:/bea/mydomain”)
print “Done creating and writing the domain”
closeTemplate()

After we had our minimal domain setup, I started a Node Manager using all the defaults. By default the Node Manager Server is started at port number 5556 and all the logs will be written to the directory where WLST is running. For more options check out the help for startNodeManager via help(‘startNodeManager’). Now once I have the Node Manager up and running, I used the command nmConnect to connect to the Node Manager and started the administration Server. After the server is started I connected to the server. Here’s the script that I used.

# start the Node Manager, this starts at
# default port 5556
startNodeManager()
# connect to the NodeManager, the default admin
# username and password can be used
nmConnect(“weblogic”,”weblogic”)
# start the server via the NM
nmStart(“myserver”)
# now disconnect from NM
nmDisconnect()
# connect to the administration server that we just started
connect(“weblogic”,”weblogic”)

If you notice I used the administration username and password to connect to the NodeManager server. This is because by default the username and password are set to the administration server’s username and password in development mode. If you set up your domain to run in production mode you will have to explicitly set this username and password via the SecurityConfigurationMBean’s NodeManagerUsername and NodeManagerPassword attributes. Here’s the WLST console output after running both the scripts.

D:\bea\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> execfile(“d:/bea/domain.py”)
Read the default domain
Done creating and writing the domain
wls:/offline>execfile(“d:/bea/start.py”)
Launching Node Manager …
Successfully launched the Node Manager.
The Node Manager process is running independent of the WLST process
Exiting WLST will not stop the Node Manager process. Please refer
to the Node Manager logs for more information.
The Node Manager logs will be under D:\bea\mydomain\.

Connecting to Node Manager …

Successfully connected.

Starting server myserver

Server myserver started successfully

Successfully disconnected from Node Manager

Connecting to weblogic server instance running at t3://localhost:7001 as username weblogic …

Successfully connected to Admin Server ‘myserver’ that belongs to domain ‘mydomain’.

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.

wls:/mydomain/serverConfig>

To recap what we did so far, I created a minimal domain from a template (that ships with BEA WebLogic Server), started a Node Manager Server, connected to it and started the administration server in the domain we created, disconnected from Node Manager Server and connected to the administration server that we just started.

I will continue the demo in my next blog entry.

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