In this step you start the clustered domain, and then deploy the application to the cluster.
To start the cluster, you use a script called
startcluster.py. Since starting servers with WLST utilizes the WLS Node Manager, first you start the node manager and connect to it. Then, you start the Admin Server, and connect to it. Finally, you start the cluster.
The following code is from the
# set the following values if your installation is different bea_home='c:\wls9' weblogic_home='c:\\wls9\\weblogic90' # nmhome and domaindir are based on the above settings nmhome = weblogic_home + '\\common\\nodemanager' domaindir = bea_home + '\\user_projects\\domains\\' + sys.argv # Start the node manager process startNodeManager(verbose='true', NodeManagerHome=nmhome) #Connect to the node manager nmConnect(domainName='myclusterdomain',domainDir=domaindir) # Start the Admin Server nmStart('AdminServer') # Connect to the Admin Server connect('weblogic','weblogic', sys.argv) # Start the cluster comprising of ms1 and ms2 start(sys.argv,'Cluster') exit()
To run the script, type:
wlst.cmd startcluster.py t3://localhost:9001 myclusterdomain wlsCluster
To deploy the application, you use the script called
deploy.py. Here I am assuming you use the demonstration application, helloApp, which is part of the
wlst-scripts.zip download accompanying this tutorial (see the
The key command in the deploy script is:
Note that since the WLST deploy command is an online command, the deploy script first connects to the Admin Server. The
deploy.py script assumes you'll pass in the following information:
appName is hard-coded to
workshop_cluster_deployment, to be consistent with Workshop (as you'll see later).
To run the script, type:
wlst.cmd deploy.py t3://localhost:9001 /wlst-workshop/helloApp wlsCluster http://localhost:9101/helloApp/hello.html
Note that two other scripts are provided (
startserver.py), which stop and start one of the two managed servers. I'll use this to show failover in the second part of this tutorial.
At this point you've used WLST to start the cluster and deploy the application to the cluster. Let's now run it!
Let's now look at running the application from the browser. The script in Step 2 will invoke the browser with the URL below, or alternatively you can click here: http://localhost:9101/helloApp/hello.html.
Voila! You should see the application. You can now type in your name, and then click on "Submit name." A JSP (called hello.jsp) will be invoked that will say hello to you and print session information, which you'll use later.
You can also go to: http://localhost:9102/helloApp/hello.html and see the same application running on the other managed server. Of course, this setup is not very useful in practice; what you really want is for client requests to be automatically load balanced across the two servers, thereby achieving better scalability. To do this, you need to introduce a load balancer to front end the HTTP requests. The Apache Web Server, with the WebLogic Apache plug-in, is one such load balancer.
You'll first need to download and install the Apache Web server, and then install the Apache HTTP Server Plug-in. Note that the plug-in is not installed by default when you install WebLogic Server—you need to select Custom Install and select the plug-in check box.
You add the following snippet to the Apache
http.conf configuration file, to configure the plug-in:
LoadModule weblogic_module modules/mod_wl_20.so <IfModule mod_weblogic.c> WebLogicCluster localhost:9101,localhost:9102 MatchExpression /hello </IfModule>
This tells the plug-in to look for URLs with the string
/hello and to redirect such requests to the cluster, represented by
localhost:9102. When both servers are available, the HTTP Server will load balance requests. When only one of the servers is available, all the traffic will be routed to that server.
Now bring up a browser and simply type:
The request will now go to the Apache HTTP Server (set up using the default Port 80), which then routes to one of the available managed servers. To see which managed server serviced the request, you can use the
getstatus.py script. Note that if you are using WebLogic Server 9.1 you'll need to copy the supplied
getstatus.py.91 script into
getstatus.py, to account for runtime MBeans changes between the two releases. This script uses the runtime MBean
InvocationTotalCount for the
hello.jsp service on each managed server to report how many times the
hello.jsp service was invoked. The output will look something like:
ms1 count: 1 ms2 count: 0
This tells you that
ms1 serviced the request.
At this point, you have used WLST to create a fully functional clustered environment for testing the application. You can now iteratively make changes to the app, redeploy the app to the cluster and test. WLST and the scripts provided here do all the hard work, so you as a developer can focus on your application, and quite easily test in a clustered environment.
Let's take a look at these three steps again: create, start, run—this time, right from the BEA Workshop IDE. I'll primarily use JSP functionality in the example. Workshop provides a professional JSP source editor, code completion, custom tag library support, simultaneous two-way source and visual JSP editors, JSP 2.0 (including EL), JSTL, a graphical editor for TLDs, and a graphical editor for
To get started, first you'll need to extract the workshop-scripts.zip into your Workshop workspace, under
Now, you'll need to bring the helloApp application into Workshop. You can accomplish this by typing File->New->Web Application Project, and then selecting Existing Web Application. You'll then see a screen similar to that shown in Figure 1.
Figure 1: Bringing an existing application into Workshop
Now browse to the location of the helloApp directory (under
c:\wlst-workshop), and click Finish. You'll be asked whether to create a default source folder; click Yes.
The traditional way to run Web apps in Workshop is to deploy against a single-server environment. To do this, first you create an empty domain using the Configuration Wizard, which is available from the Start Menu->All Programs->BEA Products->Tools->Configuration Wizard. Select all defaults, except when prompted for username and password; use
weblogic for both. Also, when prompted to name the domain, call it
Note that you could also create this domain using WLST; however, for a basic domain such as this one, the Configuration Wizard does a nice job at getting you up and running quickly.
After creating the domain, go back to Workshop and invoke the Run command:
Figure 2: Invoking the Run command
Figure 3 shows the resulting screen.
Figure 3: Running helloApp using the Workshop Run command
Select the helloApp project and then specify your Server Configuration by going to the Run with server entry and clicking on New. You now need to populate the server configuration. Figure 4 shows the values that you used.
Figure 4: Entering server information for Weblogic Server
Now click Run on the previous screen. Workshop will ask you if you want it to create the
weblogic.xml file, since helloApp does not have one; select Yes. The server instance will then be started with helloApp deployed. The script will also invoke the browser with the URL below, or alternatively, you can click here:
http://localhost:7001/hello.html. Note also that you no longer need to put helloApp in the URL as the
weblogic.xml file specifies this app as belonging to the root context (/).
When Workshop deploys the application, it uses a hard-coded application name of
__nitrox_autoconfig_deployment. If you go to the Admin Console and click on deployments, this is the name you'll see. You follow a similar paradigm for cluster deployment but to avoid conflict you use