Oracle WebLogic Server 11g for IT OPS

WebLogic Server 11g for IT Operations
Name – Rakesh Gujjarlapudi

Email Address – rakesh_gujj@yahoo.com

Introduction
This document introduce through the setup, configuration, and operation of a production configuration
of WebLogic Server. The goal of this document is for IT Operators to quickly become familiar with
WebLogic Server and understand some of its most important capabilities. The version of the application
server that will be used throughout the labs is WebLogic 10.3.4.

Assumption: WebLogic server is already installed on the machine with Windows operating system

WebLogic Server 11g Info:
1. MIDDLEWARE_HOME=c:OracleMiddleware
2. Configuration Wizard = ${MIDDLEWARE_HOME}wlserver_10.3commonbinconfig.cmd
3. By default the admin server in each domain will listen to requests at port 7001.
4. The Admin Server Console for the domain can be accessed with the URL:
http://<machine_ip>:7001/console

Oracle XE Info:
Database Version: 10.2.0
(10g) XE

Installation folder:
c:oraclexe

User: sys / oracle

User: system/oracle

Oracle Weblogic 11g Page |2

Lesson 1: Creating a WebLogic Domain
Summary
This lesson will teach how to create a domain in 2 different ways:
1. WebLogic Domain from scratch
2. WebLogic Domain based on a domain template

We can use either a Graphical User Interface (GUI) or the command line tool to create a domain.
Command line tool will do everything you can do with the GUI.

Clean-up work

Verify that there are no existing domain folders in the following directory.
 Change directory to c:OracleMiddlewareuser_projects.
 Delete any folder that may exist in this directory.

Note: This is required to avoid any conflicts

Creating a WebLogic Domain from scratch
1. To create a WebLogic Domain from scratch, use the Domain Configuration Wizard.
Access the Configuration wizard from the “Start Menu” on your Windows XP image as
shown:

2. Follow prompts and enter the fields as shown:

Field Value
Domain Name wls_domain
WL Username weblogic
WL Password welcome1


3. Steps

Step 1

Step 2


Step 3

Step 4


Step 5
For the JDK, choose either the Sun JDK or the JRockit JDK since WebLogic supports
both. Select JRockit. Select the default “Development mode” for WebLogic Startup
mode.

Step 6
Click on the “Next” button for the next couple of screens until you arrive at the
“Configuration Summary” screen as shown below. Now click “Create”. This will
create the domain and all the artifacts required to run a domain.


Step 6
On the Domain summary screen, note the location on the file system where the
domain folder has been created as well as the host and port number where the
domain will listen for requests. By default, WebLogic Domains listen to unencrypted
requests at port 7001 and encrypted requests at 7002. Click on “Start Admin Server”
and then “Done”. This will close the wizard and automatically start the Admin server
in a separate command window.

Step 7
You should see the command window that WebLogic runs in pop up. To determine
that the domain is done starting, look for “RUNNING mode” and the correct listen
address above it.


Step 8
Using either Internet Explorer or Firefox, visit the WLS console at
http://<hostname>:7001/console and verify that you can log in as
weblogic/welcome1. Note that you can use “localhost” or your hostname as part of
the URL, and this is entirely configurable. You may see the following screen saying
that the application is being deployed followed by the login screen. This is normal

Step 9


Step 10

The WebLogic administration console pictured below allows a user to start and stop
server, create clusters, configure parameters, configure JDBC data sources,
configure JMS connection factories, queues and topics.

Step 11
Logout of the admin console and stop WebLogic that is running in the window. To
stop it, you can hit Ctrl+C in the window where WebLogic is running. Or (better for
real-life scenarios), there is also a stop script located in the <DOMAIN_HOME>/bin
directory that is usually customized and run. The following screen shows the stop
script about to be executed from another prompt:

Note: <DOMAIN_HOME> in our exercise is
c:oraclemiddlewareuser_projectsdomainswls_domain.


Creating a WebLogic Domain from a domain template

Create a WebLogic domain using a pre-packaged domain template which includes a WebLogic
domain, a configured connection pool, and a deployed application. This is a typical way to build
a production domain, since it ensures consistency with other environments. Although GUI is
used here, this is entirely scriptable, and allows for cross-platform work. Navigate to the
configuration wizard as shown below

A pre-configured template that is wls_domain.jar is provided

Start the configuration wizard and step through the following screens:

Oracle Weblogic 11g P a g e | 10

Step 1

Step 2


Step 3
On the next screen, make sure to change the domain name from the default “wls_domain”
to “wls-domain_template”. Failure to do will result in overwriting and corrupting the domain
created in the previous exercise.

Step 4

Accept the default values on the next few screens


Step 5

Step 6

On the Configure JDBC Data Sources screen, select wls as shown below and enter the password as “oracle”.
Then select “Next” to proceed to the next screen.


Step 7

Step 8
Select “Deployment and Services” on the next screen as shown below in order to see what
applications have been deployed and what services have been pre-configured in this domain
template:


Step 9

Step 10


Step 11
Create the domain by selecting the “Create” button on the Configuration Summary screen

Step 12
Once the domain has been created, check “Start Admin Server” and select “Done”. This will
close the domain configuration wizard and automatically start the WebLogic server


Step 13
Verify the domain has started by looking for “RUNNING MODE” and the listen port as verification that the
server has started. By default the server will listen for requests on port 7001 on the localhost

Step 14
Using a browser, access the WebLogic console using the URL
http://<hostname>:7001/console and verify that you can login as “weblogic/weblogic1”.


Step 15

Step 16
Click on “Deployments” under “Domain Structure” and notice that the application “DizzyHR” that had been
pre-deployed in the domain template is listed


Step 17
Also navigate to “Services” and then “Data Sources” and notice that the data source “wls” that we tested
during domain creation is also listed

Logout of the admin console and stop WebLogic that is running in the window. To stop it, you can hit Ctrl+C in
the window where WebLogic is running. Or (better for real-life scenarios there is also a stop script located in
the <DOMAIN_HOME>/bin directory that is usually customized and run.


Lesson 2: Creating a WebLogic Domain
Summary
Create a WebLogic cluster with two managed servers. Below is a diagram of a typical
environment for a highly-available clustered deployment of WebLogic Server. In this
configuration, WebLogic Server runs an application that a user has deployed on two “managed
servers” that are running on two physically separate servers. These managed servers are
configured as a WebLogic Server “cluster” to support failover and high availability. Additionally,
two web servers are configured in front of the cluster and proxy requests to the two managed
servers in the cluster.

Following is the definition of the physical and logical names and configuration parameters
needed to define the WebLogic Server Environment.

Machine 1

Server Names Non-Secure Port Secure Port

AdminServer_foo 7001 7001

MS1 8001 8002

MS2 9001 9002

nodemanager 5556

apache 80 443

NOTE 1: Ideally, it is best to put the Admin Server on its own machine just as a separation of
concerns
(manager versus operational servers that are managed).

NOTE 2: Naming convention “AdminServer_X” is handy where “X” is the name of the domain
that this
AdminServer manages. In this case it is the “foo_domain”.

Middleware Home:

This is the environment variable “MW_HOME” indicating where WebLogic Server 10.3.4 is
installed. The default value for this workshop is:
C:OracleMiddleware

Domain Name and Location:

Location: $MW_HOMEuser_projectsdomains
Name: foo_domain

Cluster Names multicast port #s:

app1_cluster 239.192.0.0/7001


Configuring Domain

1. Start the Domain Configuration Wizard. On Windows, select
Start -> All Programs -> Oracle WebLogic -> WebLogic Server 11gR1 -> Tools ->
Configuration Wizard.

Alternatively, you can run the command:
C:OracleMiddlewarewlserver_10.3commonbinconfig.cmd

2. Below are screenshots stepping through the creation of the domain using the Oracle WebLogic
Configuration Wizard


3. Enter the domain name: “foo_domain”


4. Specify the Username and Password for the administration user – typically set to
“weblogic/welcome1”

5. Select JRockit and Production mode


6. Next, select to customize both the “Administration Server” and “Managed Servers…” settings:

7. Set the Administration Server settings to the following:

Name: AdminServer_foo
Listen Address: “All Local Addresses”
Listen Port: 7001
SSL Listen Port: 7002
SSL Enabled : Checked


8. Configure Managed Servers by selecting the “Add” button and enter the information as shown
below:

9. Configure the cluster as shown below. WebLogic supports both unicast
and multicast communication between cluster members. For this lab,
make sure to choose multicast.


10. Assign each managed server to the cluster by selecting the managed server with
the mouse then clicking on the button to move the managed server under the
cluster.


11. Configure Machines – Note that the “Machine” tab is for Windows boxes and “Unix Machine”
tab is for Unix boxes. In real production systems, you are required to put in the hostnames/IP
addresses that are in DNS.

12. Assign all three of the servers to the machine (host1) that you just created.


13. In the Configuration Summary screen, review all the config information. Select the “Create”
button to create the domain. Don’t select “Start Admin Server” as you did previously. Instead
just select “Done”.

14. It may be desirable to modify the startup memory parameters of the servers. To do this, one
would have to modify the “setDomainEnv.cmd” script in the domain’s home directory.
These would be in the directory:
C:OracleMiddlewareuser_projectsdomainsfoo_domainbin

Accept the default parameters.

Starting Admin Server
1. Start the Admin server. One can do it either through the Windows Menu or
through the command line tool. In order to start the admin server from the
Windows Menu follow the path shown in the screen shot below:


One can also start the admin server from the command prompt by navigating to
C:OracleMiddlewareuser_projectsdomainsfoo_domainand running startWebLogic.cmd

2. A command-window will run the JVM with a WebLogic Server instance
displaying the console output for the admin server. Put in the admin
credentials specified when the domain was created (weblogic/welcome1–
later we’ll discuss how to eliminate the need for typing credentials in by
hand).

3. Wait for WLS to fully startup. Look for the string “Server started in RUNNING mode” in the
console window


4. Verify that the admin server is working properly by using a browser to
navigate to the admin console. You should be able to use the URL:
http://localhost:7001/consoleThe username/password is
“weblogic/welcome1”.

5. Verify domain configuration by drilling into the foo_domain -> Environment ->
Servers node on the “Domain Structure” left-hand-navigation. Note that all the
managed servers will be in the “SHUTDOWN” state and that the
AdminServer_foo is in the “RUNNING” state.


6. Drill into the “Clusters” selection on the left-hand-navigation and verify cluster
config. Note that there should be two managed servers (MS1 and MS2) mapped
to the cluster app1_cluster.

7. Note the “Change Center” in the upper left corner of the admin console. This
is an important feature for managing WLS. It allows any change that’s made
through the console to be transactional – that is, whatever is done within a
“Lock & Edit” session can be undone. It also keeps multiple administrators
from stepping on each other’s’ toes by acting as a semaphore.


Starting Managed Servers
1. Open a command-window in the directory and change directory to
C:OracleMiddlewareuser_projectsdomainsfoo_domainbin

2. Use the startManagedWebLogic.cmd script to start one of the managed servers:

startManagedWebLogic.cmd MS1 http://localhost:7001

3. Enter the authentication credentials when prompted (weblogic/welcome1)

4. Go to the admin console to make sure it reflects the correct state of that managed server.

5. Start the other managed server on a separate command prompt. Change
directory to c:OracleMiddlewareuser_projectsdomainsfoo_domainbin.
Run the following command:
startManagedWebLogic.cmd MS2 http://localhost:7001

6. Enter the authentication credentials when prompted (weblogic/welcome1).

7. Note that after each managed server starts, a directory with that managed
servers runtime information will be created under the “servers” directory
(in our case:
C:OracleMiddlewareuser_projectsdomainsfoo_domainservers)

8. Ensure that you can see the state of all servers as “RUNNING” in the Admin Console. This
includes the Admin Server and the two managed servers


9. Now stop all the managed servers and the Admin server using the Admin console. Click
on the “Control” tab

10. Select all three servers by clicking on the checkbox to the left of the server name. From the
“Shutdown” menu, select “Force Shutdown Now”.

11. When the “Server Lifecycle Assistant” is displayed, click the “Yes” button


Lesson 3: Eliminating Need to enter Username/Password During
Server Startup
Summary:

Prompting to enter the username/password every time to start a server can be tedious.
We need ability to start a server automatically via a script or through the WebLogic
Nodemanager process. In order to avoid doing this, WebLogic provides users the ability
to store the username/password in an encrypted file called “boot.properties” and
hence automate the start-up process.

Creating a boot.properties file

1. Stop any running managed servers and Admin server
2. Place the following two lines in a text file:
Username weblogic
Password welcome1
3. Save the file as boot.properties and locate it in the security directory of the server’s
root directory.
C:OracleMiddlewareuser_projectsdomainsfoo_doma
inserversAdminServer_foosecurity
4. Restart the Admin server
a. At restart, the server reads the file and then overwrites it with an
encrypted version of the username and password
b. Note that you won’t have to enter the username and password for starting the server
any more after you do this.
5. Check out the contents of the boot.properties file after AdminServer_foo has
restarted
and you’ll see that the username and password have been encrypted.
6. For every managed server on each host, you’ll need to copy this new
securityboot.properties file into that managed server’s directory
(you’ll need to create the security directory too).
7. Restart all managed servers using the startup scripts. Verify that you are not
prompted for the credentials to start the servers.

P a g e | 35

Lesson 4: WebLogic Nodemanager

Summary:

Server instances in a WebLogic Server production environment are often distributed across multiple
domains, machines, and geographic locations. Node Manager is a WebLogic Server utility that enables
you to start, shut down, and restart Administration Server and Managed Server instances from a
remote location. Although Node Manager is optional, it is recommended if your WebLogic Server
environment hosts applications with high availability requirements.

A Node Manager process is not associated with a specific WebLogic domain but with a machine. You
can use the same Node Manager process to control server instances in any WebLogic Server domain, as
long as the server instances reside on the same machine as the Node Manager process. Node Manager
must run on each computer that hosts WebLogic Server instances—whether Administration Server or
Managed Server—that you want to control with Node Manager.

Configure a Nodemanager service that can be used to start and stop the Administration server and the
Managed Servers. Node Manager must run on each computer that hosts a WebLogic Server instance.

Nodemanager Setup:

1. Verify that no managed server instances are running. If they are, stop them by issuing Ctrl-C in
the command prompt.
2. Run the Admin Server by running the script “startWebLogic.cmd” from directory
c:oraclemiddlewareuser_projectsdomainsfoo_domain
This will start the Admin Server
3. Verify that the server has started by looking for the “RUNNING” mode in the console window
4. Using the browser navigate to the admin console by using the URL
http://<hostname>:7001/console.
5. Login to the admin console using credentials “weblogic/welcome1”
6. Navigate to “Environment -> Servers and then click on the “Control” tab

P a g e | 36

7. Click on the checkbox next to the server “MS1” and then click on the “Start” button

Notice that the command failed and there is an error message both on the admin console and
the command prompt where the admin server is running. The command failed because
Nodemanager service configured on this host

P a g e | 37

Configure a Nodemanager service on this host and issue the same command

Installing Nodemanager service

8. Open a windows command prompt and run the following command to install Node Manager as
a Windows Service:

C:OracleMiddlewarewlserver_10.3serverbininstallNodeMgrSvc.cmd

9. Verify that it was installed as a service by opening up the “Services” control panel and looking
for “Oracle WebLogic NodeManager…” (Start -> Control Panel -> Administrative Tools ->
Services)

P a g e | 38

Start the node manager by selecting the “Start” link or the play icon

Configuring Nodemanager on localhost
1. Login to the admin console by using a browser and navigating to the URL
http://localhost:7001/console.
Use weblogic/welcome1 for user credentials
2. Lock & Edit admin session in the Change Centre

3. On the right hand side click on “Domain” under Domain Configurations
Under “Settings for foo_domain”, Click on Security->General and then expand the “Advanced”
Tab

P a g e | 39

For the fields “Nodemanager Username” and “Nodemanager Password” enter
weblogic/welcome1. These credentials will be pulled over by nodemanager when the
nodemanager is enrolled with the nmEnroll WLST directive later. These will be the credentials
that the admin server uses to authenticate to the nodemanager. Since a nodemanager can
manage multiple domains on a single system, different credentials can be specified for each
domain

4. Save changes by clicking on the “Save” button on the bottom
Activate the changes in the Change Centre by selecting the “Activate Changes” button

P a g e | 40

Testing Nodemanager

1. In the admin console, navigate to Environment->Machines and select host1 (the name we
specified for the machine during domain configuration)

Select the “Monitoring” tab at the top – you should be able to see the status “Reachable”. If this
isn’t the status, then Nodemanager isn’t communicating properly with the AdminServer_foo.

2. Navigate to Environment->Servers and select the “Control” tab.

Select the checkbox next to MS1 and click on the “Start” button. Before we installed the
Nodemanager service, this operation had failed. Let us see what happens this time around

When the Server Life Cycle Assistant screen is displayed, click on Yes.

You can select the little turning arrows to have the console auto-refresh
3. Observe the server state transition from “UNKNOWN” or “SHUTDOWN” to “STARTING” and
finally to “RUNNING”.

P a g e | 41

Lesson 5: Deploying Applications

Summary:

IT Operators are often required to deploy applications into their WebLogic environments. In this
lesson, we will walk you through a typical deployment scenario. A sample application,
“whichServer.war”.

This is a simple JSP application which reads session runtime information to tell you which managed
server it is being served up from. It also increments an integer and then stores it into the HTTPSession,
simulating the storage of state information. The application whichServer.war has been configured to
share its session state within the WebLogic cluster. This gives it high application availability and the
guarantee that the session information will not be lost if one of the nodes in the cluster goes down.

The session replication is enabled by adding the following parameters to the weblogic.xml file for the
webapp:

<session-descriptor>
<persistent-store-type>REPLICATED</persistent-store-type>
</session-descriptor>

Deploying Application:

1. Ensure that the admin server and the managed servers are started by accessing the admin console
and going to Environment->Servers. Verify that the state of the admin server and the managed
servers MS1 and MS2 is shown as “RUNNING”.
2. Go to the Environment -> Deployments section of the console.
3. Create an admin session by selecting the “Lock & Edit” button in the Change Centre
Select the “Install” button on the right hand side of the screen under “Deployments”

4. Navigate to the folder where whichServer.war resides and select it.

P a g e | 43

Select Next
5. Install this as an application (versus a library)

6. Select “Next”. Then target all servers in the app1_cluster

P a g e | 44

7. Select “Next”, then accept the default values given on the next page

8. Select “Next” then “No, I will review the configuration later”

9. Finally select “Finish”. Activate the changes in the Change Centre by clicking on the Activate
Changes button. The state of the deployment will go from “Distribution Initializing” to “Prepared”
You must now activate the application by first selecting the checkbox next to “whichServer”,
P a g e | 45

then selecting the “Start Servicing All Requests” pulldown.

Confirm that you want to activate/start this deployment. You will see the state changed from
“Prepared” to “Active” (You may have to refresh your browser).

Testing Deployment

1. Since we deployed the application in the app1_cluster, we can access the web application by
navigating to the following URL:

http://localhost:8001/whichServer/whichServer.jsp

http://localhost:9001/whichServer/whichServer.jsp

2. Now Refresh the page several times (F5) to see the stored value increment

P a g e | 46

Lesson 6: Apache Plugin Installation and Testing for Load Balancing,
Session Stickiness, Failover and Session Replication

Summary:

A typical environment for a highly-available clustered deployment of WebLogic Server is depicted below

In Lesson 2, we created a cluster.
In Lesson 4, we installed the Nodemanager service.
In Lesson 5, we deployed an application to the members of the cluster.
In this lesson, we will configure a web server proxy and test our application for load balancing (even
distribution of sessions across the nodes of the cluster), session stickiness (sending subsequent
requests from a session to the same node), failover (sending the request to an alternate node if the
node originally managing the session is not available) and session replication (maintaining session state
across the nodes of the cluster, thus making the application highly available).

The best way to front-end a WebLogic Server cluster is through a load-balancer of some kind. This way,
clients can hit a single endpoint and get load-balanced between all nodes of the cluster. WebLogic
Server comes out of the box with plug-ins for Apache, Microsoft IIS, and the Oracle Sun Java
WebServer.

Apache Plugin is taken as an example in this lesson. Apache Server will be configured to load balance
requests across both of the managed servers MS1 and MS2 in the cluster

P a g e | 48

Apache Plug-in Setup

1. Install Apache HTTP Server
Accept all the defaults while installing the Apache web server
On Windows it normally installs into the directory C:Program FilesApache Software
FoundationApache2.2

2. The apache-weblogic proxy plugin is distributed with WLS 10.3.4 – find it in the
“[MW_HOME]/wlserver_10.3/server/plugin/…” directory
Since our VM is a Windows 32-bit machine, choose the Win->32 folder
(C:OracleMiddlewarewlserver_10.3serverpluginwin32)

3. Copy mod_wl_22.so into the directory C:Program FilesApache Software
FoundationApache2.2modules
Edit C:Program FilesApache Software FoundationApache2.2confhttpd.conf and
Add the following lines at the end of the section where are the other LoadModule directives are:

LoadModule weblogic_module modules/mod_wl_22.so

<IfModule mod_weblogic.c>
WebLogicCluster localhost:8001,localhost:9001
MatchExpression *
</IfModule>

NOTE: No spaces can exist between the cluster members

4. In the admin console (URL: http://localhost:7001/console weblogic/welcome1) go to the
Environment->Clusters and then click on the app1_cluster

5. On the next Screen, click on “Advanced”
P a g e | 49

6. Click on “Lock & Edit” in the change centre

7. Check the “WebLogic Plug-in Enabled” checkbox

Click on “Save” at the bottom of the screen. Since we have to repeat these steps for the
managed servers MS1 and MS2, we will not activate our changes now.

8. Click on Environment->Servers and then click on MS1

P a g e | 50

9. Click on the “General” tab under “Settings for MS1” and then click on the “Advanced” button at
the bottom.
Check the “WebLogic Plug-in Enabled” checkbox

10. Save changes by clicking on the “Save” button at the bottom of the screen
Repeat steps for managed server MS2. Remember to save your changes by clicking on the
“Save” button.

11. Activate changes by clicking on the “Activate Changes” button in the Change centre

12. Re-start both the managed servers MS1 and MS2. In the admin console, navigate to
Environment->Servers and then on the right hand screen click on “Control”.

Select the checkbox next to the managed servers MS1 and MS2

P a g e | 51

13. First click on “Shutdown” and choose “Force shutdown Now”.

Select “Yes” on the Service Lifecycle Assistant screen.

The state of the two managed servers will change eventually to “SHUTDOWN”.

14. Select the checkbox next to the two managed servers MS1 and MS2.

Now click on the “Start” button. Select “Yes” on the Service Lifecycle Assistant screen. The state
of the servers will eventually change to “RUNNING”

P a g e | 52

15. Now re-start the Apache service by going to the windows Start Programs and following
Programs->Apache HTTP Server 2.2->Control Apache Server->Restart

Now access the application that we deployed previously through the apache web server proxy
by using the URL: http://localhost/whichServer/whichServer.jsp. Notice that since the web
server is running on port 80, we do not have to specify the port number explicitly.

P a g e | 53

Testing Load Balancing, Session Stickiness, Failover and Session Replication

Since we deployed the application in the app1_cluster, and we have an Apache HTTP server fronting
requests for the cluster, we can now test the application for

 Load Balancing (even distribution of sessions across the nodes of the cluster),
 Session Stickiness (sending subsequent requests from a session to the same node),
 Failover (sending the request to an alternate node if the node originally managing the session is
not available) and
 Session Replication (maintaining session state across the nodes of the cluster, thus making the
application highly available).

Step 1
To test load balancing, use your default web browser (Firefox in this example) to access the application
by using the URL: http://localhost/whichServer/whichServer.jsp

Notice the name of the managed server serving this request, MS1 in our case

Step 2
Now use an alternate web browser (like Internet Explorer or Google Chrome) to access the
application by using the same URL: http://localhost/whichServer/whichServer.jsp

P a g e | 54

Notice that the request has been served by a different managed server in the cluster

Step 3

Now we will test session stickiness, failover and session replication. In order to do that, refresh the
page in the first web browser to increase the counter up to a certain value. Notice that this
demonstrates session stickiness by having the same managed server handle all subsequent requests

Step 4
Now go to the WebLogic Admin Console and use the Environment -> Servers -> Control tab to shut
down the managed server serving the request (MS1 in our example)

After confirming your request, go back to the browser and refresh the page (F5) to see what happens

P a g e | 55

Notice that failover has been demonstrated by having a different server of the cluster serve such
request. However, the counter went back to “1”, so the session state is not being maintained. What
could be causing this issue?
Step 5

In order to fix it, we need to edit the weblogic.xml file, located on the WEB-INF folder of the
whichServer.war file (C:WLS-Admin-Workshop-LabLab-MaterialLab5-
AppDeploywhichServer.warWEB-INFweblogic.xml)

P a g e | 56

Use Notepad to uncomment the <session-descriptor> element by deleting the “”
characters before and after the element

Save (Ctrl-S) and close the file, accepting the update dialog after it has been closed

P a g e | 57

Now the application is ready to be redeployed and tested for high availability
Step 6

First, let’s bring the previously shutdown managed server back up by going to the WebLogic Admin
Console and using the Environment -> Servers -> Control tab to startup the managed server (MS1 in
our example)

Activate the automatic refresh function to ensure the managed server goes back to RUNNING
Mode

P a g e | 58

Now let us redeploy the application by going to Edit mode (if not already there) and navigating to the
Deployments section of the WLS Admin Console

Select the whichServer application and click “Update”

P a g e | 59

Now activate the changes by clicking the “Activate Changes” button on the Change Centre section of
the WLS Admin Console

P a g e | 60

Step 7

Validate that all changes have been applied and the whichServer app state is shown as “Active” on the
“Deployments” section

Step 8

Now let’s test the application for session replication (aka high availability). Go back to the whichServer
application and refreshing the page several times to increase the number of the counter

P a g e | 61

Now go to the WebLogic Admin Console and use the Environment -> Servers -> Control tab to shut
down the managed server serving the request (MS2 in our example)

After confirming your request, go back to the browser and refresh the page (F5) to see what happens

P a g e | 62

Step 9

Notice that the managed server changed but the counter continues from the last value, thus
demonstrating that the session is being replicated among the managed servers of the cluster, giving
high availability to the application

As an optional step, in case you want to test the Load Balancing, Session Stickiness, Failover and
Session Replication with an alternate application, you can bring back up all managed servers, deploy
and activate the InMemRepClient.war application found in C:WLS-Admin- Workshop-LabLab-
MaterialLab5-AppDeployInMemRepClientApp, and access it thru the URL
http://localhost/InMemRepClient/Session.jsp

Stop the managed server and admin server instances either through the admin console (Environment-
>Servers->Control; select servers and then select “shutdown” and “Force shutdown Now”) or by hitting
Ctrl-C in the windows command prompt.

P a g e | 63

Lesson 7: WebLogic Scripting Tool (WLST)
Summary:
The WebLogic Scripting Tool (WLST) is a command-line scripting interface that system administrators
and operators use to monitor and manage WebLogic Server instances and domains. The WLST scripting
environment is based on the Java scripting interpreter, Jython .

WLST lets you perform the following tasks:

 Propagate a WebLogic Server domain to multiple destinations using predefined configuration
and extension templates.

 Retrieve domain configuration and runtime information.

 Edit the domain configuration and persist the changes in the domain's configuration files.

 Edit custom, user-created MBeans and non-WebLogic Server MBeans, such as WebLogic
Integration Server and WebLogic Portal Server MBeans.

 Automate domain configuration tasks and application deployment.

 Control and manage the server life cycle.

 Access the Node Manager and start, stop, and suspend server instances remotely or locally,
without requiring the presence of a running Administration Server.

In this lesson, a brief introduction to the WebLogic Scripting Tool (WLST) will be provided

Activity Steps:
1. Stop all running admin server and managed server instances.

2. From windows command prompt and change directories to
c:oraclemiddlewareuser_projectsdomainswls_domain.

3. Run the startWebLogic.cmd script.

4. Verify that the server is running by looking for the “RUNNING” mode in the command
prompt.

5. Using a browser navigate to the URL http://localhost:7001/console in order to access
the admin console.

6. User the user credentials “weblogic/welcome1” to login to the console.

Running WLST:
P a g e | 64

Step 1

There are different ways to start the WLST tool. One way is to run the tool from the Windows
Start Menu as shown

The other way is to start a windows command prompt and run the tool from the command line.
In our installation, the tool resides at c:oraclemiddlewarewlserver_10.3commonbinwlst.cmd

Step 2
Using either steps, run the wlst tool. The tool starts in offline mode as shown below.
Offline mode means that the tool is not connected to a running server. In this mode, one can create
domains, change configuration elements and build templates for domains.

Step 3

Connect to a running domain to see the “Online” mode of WLST.
To do this, use the connect() command:

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

P a g e | 65

Step 4
Basic UNIX-style commands are available here, such as pwd(), ls(), and cd(). Run “ls()” to see what is
located in the base of the server hierarchy. Note the left side column, which indicates whether the
item is akin to a “directory”, which allows you to use cd(‘the item’) to change your location within the
tree.

Type exit() to exit out of the wlst command prompt.

P a g e | 66

Automatic Script Recording

Step 1

Users often build wlst scripts from scratch or leverage existing samples that are available with the
WebLogic distribution. Another way to create scripts that we’ll show here is to “Record” them from
the WLS console and then leverage them to automate your processes. In this activity we will illustrate
this use with a simple example
In the admin console, locate the Change Center at the top left and lock the console for editing

Step2

Now click the Script Recording button that is shown at the top of the admin console to start the
recording. The console will show you where it is placing the script you will record.

P a g e | 67

Step 3
Here we will make a change to the server’s configuration and see the resulting script. First, open
Environments -> Servers, then click on AdminServer. Once up, find the “Notes” tab and type something
in the box and save it. The following screen shots show this.

P a g e | 68

Click on the “Save” button to save your changes.

Now click on the “Record” button again to stop the recording.

Now let us go to the directory where the script has been saved which is
C:OracleMiddlewareuser_projectsdomainswls_domain

Open the script in an editor to see what was recorded.

Step 4

You will see that it recorded the directory within the configuration tree and the command it ran to
change the Note field.
Now open the following files in the folder:

C:WLS-Admin-Workshop-LabLab-MaterialLab7- WLSTWLS_ServerNote.py
C:WLS-Admin-Workshop-LabLab-MaterialLab7- WLSTnote.properties

P a g e | 69

In the WLS_ServerNote.py script, we have parameterized the value, as well as the connection string so
that we can easily make changes without having to create or modify existing scripts.

Open a command prompt and cd to C:WLS-Admin-Workshop-LabLab- MaterialLab7-WLST
Step 5

Run the WLS_ServerNote.py script using the following command: wlst.cmd WLS_ServerNote.py

Look for the activation completed message when the script finishes

Step 6

Back in the WLS admin console, navigate to Environment->Servers, then click on “Admin Server” and
then on the “Notes” tab. You will notice that server’s Notes field has been changed to a new value.

P a g e | 70

Domain Configuration using WLST
Step1

In the admin console go to Environment->Deployments and notice that no application has been
deployed.

Step 2

Go to Environment->Services and expand the services tree. Click on “Data Sources” and notice
that no data sources have been configured

Step 3

Run some pre written scripts that will automate the process of creating a Data Source as well as deploy
an application.

Now run the command: wlst.cmd WLS_Deploy.py. This script will deploy an application

You can verify this by going to the admin console and navigating to Environment->Deployments.
You will see an application listed here that was not there previously.

P a g e | 71

Step 4

Run the WLS_JDBC.py script to create a JDBC data source and verify that it has been created via the
admin console.

The WebLogic installation provides sample WLST scripts that users can leverage to build their own
scripts and automate their deployment process. These scripts allow you to configure a cluster as well
as create JMS connection factories, queues and topics. You can find these samples at
C:OracleMiddlewarewlserver_10.3samplesserverexamplessrcex ampleswlstonline

P a g e | 72

Lab 8: JRockit Mission Control (JRMC)

Summary:
Oracle JRockit Mission Control (JRMC) is a suite of tools for managing, monitoring, profiling, and
troubleshooting your Java applications. JRockit Mission Control consists of the Management Console,
the JRockit Runtime Analyzer and the Memory Leak Detector.

JRMC will be used to analyze the memoryHog application

JRockit Mission Control is installed in the folder “C:Program FilesJavajrockit- jdk1.6.0_20-R28.1.0-
4.0.1”

Starting JRMC:

Step 1
Start JRMC and the console will automatically detect the JVMs on the local system(both Jrockit and
non-Jrockit JVMs)

Step 2

In order to monitor a MemoryHog application, select it in the pick list of Local JVMs. Then right click
and select the “Start Console” button.

P a g e | 73

Step 3
You will now see the General view in the main dashboard for the application – explore the memory
and CPU statistics and note the shark-tooth pattern in memory consumption due to Garbage
Collections (GCs):

Step 4

Explore the other views in the main console such as the MBeans, Runtime, and Advanced:

P a g e | 74

In the MBeans view, triggers can be setup to create actions (such as sending an email) on specified
conditions (such as the Live Set memory being too high).

In the Runtime view, the tabs on the bottom of the screen allow one to explore the System usage
and information, Memory information such as GC pauses and algorithm. Thread information is also
available to look at information about all the live threads running in the JVM.

In the Advanced view, the tabs at the bottom enable access to the Method Profiler, Exception
Counter, and access to Diagnostic Commands that may be available in the JVM.
Step 5
Use the JRMC Memory Leak Detector. Select the memory leak tool icon in the top of the JVM Browser
as shown below:

Step 6
A new tab will be opened and the Trend Analysis screen will first come up so you can see which object
allocations are growing in the heap

P a g e | 75

Step 7
By right-clicking on the biggest object type (in this case the char[] array) and selecting “Add to Type
Graph” you can see what’s creating the objects and holding onto them

Step 8

Click on the little plus sign in the char[] array to see which objects created the char arrays
The Type Graph will now show that there are hundreds of thousands of Strings in the character arrays.
Note that the type graph will colour code the object types that are the largest – the java.lang.String is
in red along with char[].

P a g e | 76

Now, hit the plus sign to expand the java.lang.String object to see which objects are holding onto the
Strings

Example: We can now easily see that our code, com.oracle.memoryhog.MemoryHog has an inner class
called DataClass which is holding onto all the Strings. We’ve found the culprit that’s causing the leak!

Eventually, after about 129 Loops, you will see the JVM Runtime Exception in the MemoryHog
command window when the application uses all of the 500MB of RAM it was allocated:

Exception in thread "Main Thread" java.lang.OutOfMemoryError

At this point, JRMC will lose the connection to the JVM and the “Connection Lost” messages will
be seen

P a g e | 77

JRockit Flight Recorder
Step 1

It is often desirable to see what is going on in the JVM for later-analysis

You will now be able to see the status of the recording in the lower-right corner of JRMC

Once the recording is completed, the flightRecording[uniq_id].jfr file will be opened for analysis of that
minute during the recording:

P a g e | 78

Step 2

Explore the main tabs on the left to see what was going on in the application.

Step 3
Going to the Memory -> Allocation tab shows that the char[] array is huge and that the allocations
came from the methods outlined in the bottom of the window – originating at the method
com.oracle.memoryhog.MemoryHog.comsumeRAM() – Hmmm, sounds fishy! ;)

These recordings are great ways to communicate with others in the organization about what is going
on with production applications. If you notice, the size of the flight recording is also quite small – a one
minute recording is only 80KB

P a g e | 79

Oracle WebLogic Server 11g for IT OPS

Recommended

More Related Content

What's hot (20)

Similar to Oracle WebLogic Server 11g for IT OPS (20)

More from Rakesh Gujjarlapudi (16)

Oracle WebLogic Server 11g for IT OPS