Lab 1A: Installing Oracle WebLogic Server 10.3.

2
After completing this exercise, you should be able to install the Oracle WebLogic Server
10.3.2 software
In this practice, you install Oracle WebLogic Server 10.3.2 by performing the
following steps:


1.1 Run the installation program: wl s1032_wi n32. exe



1.2 Use the following configuration information:
Screen Value
Choose BEA Home Directory C: \ Or acl e\ Mi ddl ewar e
Note: Select Yes when a warning
message appears stating that The
directory is not empty, do you want to
proceed?
Choose Install Type Typical
JDK Selection Bundled JDK - BEA JRockit 1.6.0_05
SDK
Choose Product Installation Directories C: \ Or acl e\ Mi ddl ewar e\ wl ser ver _
10. 3

1.3 Review Installation Summary. Finally, deselect the Run Quickstart check box and click
Done to complete the installation.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
1




Lab 1B: Configuring a Domain


After completing this practice, you should be able to create:
a new domain using the configuration wizard


Basic Instructions

1. Configure a new domain using the Configuration Wizard.

Configure the Administration Server with the following specifications:
Name: Admi nSer ver
Listen address: Al l Local Addr esses
Listen Port: 7001
Note: Do not enable SSL.

Configure the Administrator username and password with the following specifications:
Username: webl ogi c
Password: webl ogi c1
Confirm user password: webl ogi c1

Currently, there is no need to configure additional users, groups, and global resources
roles.




2. Test the domain that was created by changing the directory to
<WORK_HOME>/ domai ns/ base_domai n and executing the following:

./st ar t WebLogi c. sh

Specify the following username and password:
Username: webl ogi c
Password: webl ogi c1
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
2
Lab 1C: Using the Administration Console


After completing this exercise, you should:
Be familiar with the Administration Console
Practice modifying the properties of Oracle WebLogic Server using the Administration
Console
Configure and view log file entries for an Oracle WebLogic Server using the
Administration Console


Oracle WebLogic Server is administered by using a Web-based Administration Console
that enables you to configure and monitor the Oracle WebLogic servers. Using Log
messages, you can detect problems, track down the source of an error, and track system
performance.



Basic Instructions

1. Start Oracle WebLogic Server for the examples domain base_domai n.

2. Use the Administration Console to modify the standard output severity threshold for the
Admi nSer ver ( admi n) to I nf o.

3. Shut down the Admi nSer ver ( admi n) server by using the Administration Console.

4. Restart the Administration Server, and then view the server logging for Admi nSer ver
using the Administration Console.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
3
Solution: Using the Administration Console


In this practice, you start and stop Oracle WebLogic Server by using the Administration
Console and view the server logs.


Start Oracle WebLogic Server for the Examples Domain base_domain.

1.1 Start > All Programs > Oracle Weblogic > User projects > base_domain > Start Admin
Server for Weblogic Server domain.



Use the Administration Console to modify the standard output severity threshold for
base_domain to Info.

2.1 Open a Web browser and navigate to http://localhost:7001/console.
Log in as:

Username: webl ogi c
Password: webl ogi c1

2.2 Navigate to base_domain > Environment > Servers > AdminServer(admin) >
Logging > General.

2.3 Scroll to the bottom of the page and click Advanced.

2.4 Set the following properties:

Redirect stdout logging enabled: Selected

2.5 In the Message Destination(s) section, set the following Standard out properties:

Severity level: Info

2.6 Save your changes.

Shut down the AdminServer(admin) server using the Administration Console.

3.1 Navigate to base_domain > Environment > Servers > AdminServer(admin) >
Control > Start/Stop. Verify that the Admi nSer ver ( admi n) check box is selected in
the Server Status table and click Shutdown.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
4
Solution: Using the Administration Console (continued)

3.2 Start the server again using the instructions in the preceding step 1.1.


3.3 Note how much more information is output to the stdout I/O stream when the server is
started again (once again, you should see a number of notices of severity <I nf o>).

View server logging for the AdminServer using the Administration Console as the log
viewer.

4.1 Open a Web browser and navigate to http://localhost:7001/console.
Log in as:

Username: webl ogi c
Password: webl ogi c1

4.2 Navigate to base_domain > Diagnostics > Log Files.

4.3 In the Log Files table, select ServerLog and click View. This allows you to view log file
entries via the console.




F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
5

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
6
Node Manager Listen Node Manager Listen
Name Address Port (Type = Plain) Server

Lab 2



Configuring Servers and Machines




After completing this practice, you should be able to:
Create WebLogic machines
Create Managed Servers
Assign Managed Servers to machines
Start Managed Servers



In this lab, you create and configure the Managed Servers server1, server2, and
server3 and machines machine1 and machine2 for the base_domain that you created
to simulate the production environment.



Specifications

Table 2 Managed Server Specifications

Server Name Listen Address Listen Port SSL Listen Port
server1 127.0.0.1 7003 7004
server2 127.0.0.1 7005 7006
server3 127.0.0.1 7007 7008


Table 3 Machine Specifications




machine1 127.0.0.1 5555 server1
machine2 127.0.0.1 5556 server2
server3
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
7
Basic Instructions

1. Using the administration console, go to base_domain > Environment > Servers
If you havent acquire the lock, click Lock & Edit in Change
Center


2. Create and configure the Managed Servers server1, server2 and
server3 by referring to the server specifications in Table 2.

3. Create and configure the machines machine1 and machine2 by referring to the
machines specifications inTable 3.

4. Test the configuration by starting the created Managed Servers using the command line,
by executing the following command that replaces <server_name> with the name of the
Managed Server (folder:C:\Oracle\Middleware\user_projects\domains\base_domain\bin):

startManagedWebLogic <server_name> http://127.0.0.1:7001



Tip: If you are using the local address for the Administration Server, you can simply
supply the <server_name> as the argument.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
8
Solution: Configuring Servers and Machines
In this practice, you configure the Managed Servers and machines.





Create the servers.

1.1 If not already open, open a Web browser and navigate to http://localhost:7001/console.
Log in as:

Username: weblogic
Password: weblogic1


1.2 Navigate to base_domain > Environment > Servers > server1 >
Configuration > General. Lock the console. Create the Managed Server
server1 to match the specifications in Table 2.

1.3 Create and configure the server2 and server3 servers in the same way as step 2.2


.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
9
Practice 2-1: Configuring Servers and Machines (continued)

2.6 Navigate to base_domain > Environment > Servers > server2 > Configuration >
General. Specify the following properties:

SSL Listen Port Enabled: Selected
SSL Listen Port: 7006
Note: Leave the machine setting at None in this step. You will assign the machines to the
Managed Servers after you create them.
Save and Activate your changes.

2.7 Similar to how you created and configured the Managed Server server2, create the
Managed Server server3 using the Managed Server specifications from Table 2.

Create and configure the machines.

3.1 Navigate to base_domain > Environment > Machines. Lock the console. Under
the Machines table, click New. Specify the following properties on the Create a
New Machine page:

Name: machine1
Machine OS: Other

Click OK.
Activate your changes.

3.2 Assign the machine machine1 to the server1 server by clicking the machine
name. Lock the console and click the Servers tab.

3.3 Click Add under the Servers table. Select server1 from the existing server drop-down
list and click Finish.

3.4 Click the Node Manager tab to enter the properties of Node Manager for this machine
according to the machine specifications (Table 3).
Note: In this training environment, you use a PLAIN text connection between Node
Manager and the servers. In production, using SSL secures the communication when
using the Java-based Node Manager.

3.5 Save and activate your changes.

3.6 Repeat this process to create the machine, machine2, by referring to the machine
specifications in
Table 3, and assign the Managed Servers server2 and server3 to machine2.
Also configure the Node Manager properties for the machine.

Test the configuration by starting the created Managed Servers.

4.1 Open a window command prompt by running the cmd command.

4.2 Change to the <WORK_HOME>\domains\base_domain\bin directory.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
10
Practice 2-1: Configuring Servers and Machines (continued)

4.3 Start the Managed Servers using the command line by executing the following
command that replaces <server_name> with the name of the Managed Server
(folder:C:\Oracle\Middleware\user_projects\domains\base_domain\bin):

startManagedWebLogic <server_name> http://127.0.0.1:7001



Tip: If you use the local address for the Administration Server, you can simply supply
the
<server_name>
argument.

4.4 If prompted, enter the Administrator credentials at server prompt.

Note: Check to make sure that all Managed Servers are up and running.
Before you start the next lab, make sure that all Managed Servers are
stopped (CTRL+ C to stop server1, 2, and 3 on terminal windows).



F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
11


Lab 3


Lab 3: Starting the Servers Using Node Manager




After completing this exercise, you should be able to:
Configure a machine for remote startup and shutdown
Configure and run Node Manager
Start and stop servers remotely



Node Manager is a J ava program running in a remote machine that allows the Administration Server to
remotely start any Managed Server instances on that machine. It can also be used to monitor the health
status of the Managed Servers on that machine. In this lab, you configure Node Manager properties for
machine2 and remotely start the Managed Server instances running on machine2 using the
Administration Console.




The Node Manager service runs on Port 5556. You must declare the AdminServers IP address
as a trusted host so that it can access the Node Manager process on machine2.


Design Specifications

Element Value

Node Manager service port for machine2 5556

IP Address of AdminServer 127.0.0.1

Node Manager service port for machine1 5555
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
12
Basic Instructions

1. Connect to the domain using WLST. Apply the nmEnroll WLST command to enroll the
machine. Navigate to Domain and set the classpath of servers.

2. Open a prompt and change to the <WEBLOGIC_HOME>/server/bin directory.
Start Node Manager to listen on port 5555 on machine1 by executing the following
command:
startNodeManager.cmd 127.0.0.1 5555

Start Node Manager to listen on port 5556 on machine2 by executing the following
command:

startNodeManager.cmd 127.0.0.1 5556

3. Start the servers using the Node Manager service.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
13
Solution: Starting Servers Using Node Manager

1.1 Start WLST by entering the following command at the prompt:
java weblogic.WLST

Note: WLST is case-sensitive.

1.2 At the wls:/offline> prompt, enter:

connect (weblogic,weblogic1,t3://localhost:7001)

1.3 After you are connected at the wls:/base_domain/serverConfig> prompt, enter
the following command:
nmEnroll ([domainDir], [nmHome])

wls:/base_domain/serverConfig>
nmEnroll(C:/Oracle/Middleware/user_projects/domains/base_domain
,C:/Oracle/Middleware/wlserver_10.3/common/nodemanager)




Start Node Manager.

2.1 Open a command prompt and change to the <WEBLOGIC_HOME>\server\bin
directory.


2.2 Start Node Manager to listen on port 5555 on machine1 by executing the
following command:
startNodeManager 127.0.0.1 5555
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
14
Practice 3-2: Starting Servers Using Node Manager (continued)

2.3 Start Node Manager to listen on port 5556 on machine2 by executing the
following command:
startNodeManager 127.0.0.1 5556

Start the servers using the Node Manager service.

3.1 Return to the Administration Console and navigate to base_domain > Environment >
Servers > server1 > Control > Start/Stop. Select the check box against server1 in
the Server Status table and click Start. When prompted to verify whether you want to
start the server1 Managed Server, click Yes.
Note: If you get an error, shut down the Node Manager associated with 5555, edit the
nodemanager.properties file under
C:/Oracle/Middleware/wlserver_10.3/common/nodemanager, and make sure
that the SecureListener property is set to true. Start Node Manager and try step 4.1 again.

3.2 Repeat the preceding step to start the Managed Servers server2 and server3.

3.3 Navigate to base_domain > Environment > Servers. Verify the running state for both the
Managed Servers server2 and server3.


3.4 Stop server1, server2, and server3 and both Node Managers.

Note: From here on, you should try to start or stop the Administration Server and the
Managed Servers using the command line rather than the Administration Console just to
be consistent. This will also allow you to see the error/debug/info messages easily on the
terminal window (especially in the case of Clustering labs).
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
15

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
16

Lab 4



Deploying and Undeploying Web Applications





At the end of this exercise, you should be able to deploy a prepackaged .war file.



Interactive, Web applications are groupings of static pages and dynamic pages for the overall
application. They can be packaged in a Web Archive file with a .war extension. They are
packaged using the J AR utility. In this lab, you deploy the Web application
helloworld.war, and also deploy and undeploy the helloworld_as_default.war
Web application.



<WORK_HOME>: C:\studentWLSS103\work


Basic Instructions

1. Deploy the helloworld.war Web application.

2. Deploy the helloworld_as_default.war Web application.

3. Undeploy the helloworld_as_default.war Web application using the Administration
Console.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
17
Solution: Deploying/Undeploying Web Applications
In this practice, you deploy, and then undeploy a Web application.





Deploy the Web application.

2.1 Start AdminServer and the server1 Managed Server if they are not already running.




2.2 Navigate to the <WORK_HOME>/lab4 directory, locate the helloworld.war file.



2.3 If not already open, open a Web browser and navigate to http://localhost:7001/console.
Log in as:

Username: weblogic
Password: weblogic1

2.4 Navigate to base_domain > Deployments. Lock the console.

2.5 If helloworld.war exists, select the helloworld application, and then click Stop >
Force Stop Now. (The state changes to Prepared. If you click Prepared, you can see
that the application is successfully stopped.) Select the helloworld application, and
then click Delete. Activate your changes, and then re-lock the console.

2.6 Lock the console. In the Deployments table, click Install. Navigate to the location
<WORK_HOME>/lab4, select helloworld.war and click Next.

2.7 On the Choose Targeting Style page, select Install this deployment as an
application, which is the default option, and click Next.

2.8 On the Select Deployment Targets page, select the server1 Managed Server in the
Servers table and click Next.

2.9 On the Optional Settings page, under the Source Accessibility header, select Copy
this application onto every target for me and click Next.

2.10 On the Review page, select No, I will review the configuration later under the
Additional Configuration header and click Finish.

2.11 Activate your changes.

2.12 Navigate to base_domain > Deployments. In the Deployments table, select the
helloworld application check box and click Start > Servicing All Requests. (Optional)
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
18
Solution: Deploying/Undeploying Web Applications
(continued)

2.14 The Summary of Deployments page should indicate the module state as Active or
Distribute Running when the deployment has been completed.

2.15 Verify that the deployment has been completed by opening a browser and navigating to
http://localhost:7003/helloworld.

This should open up the helloworld application.

Deploy the Web application helloworld_as_default.war.

3.1 Sometimes, it is convenient to set a Web application as a default Web application for a
server, so that in the request URL, you can omit the context name. You can select one
default Web application per server. In this lab, the helloworld_as_default.war
application has been configured to be the default Web application.

Note: The only difference between helloworld.war and
helloworld_as_default.war is that the latter has a deployment descriptor file
called /WEB-INF/weblogic.xml, which contains the stanza:

<weblogic-web-app>
<context-root>/</context-root>
</weblogic-web-app>

Note: A similar result could also have been achieved by navigating to Servers > server1
> Protocols > HTTP tab of the admin console and specifying value for the attribute
"Default WebApp Context Root". This way developers don't have to built-in this
information during development.

3.2 Navigate to the <WORK_HOME>/lab4 directory, locate the
helloworld_as_default.war file.


3.3 Deploy the helloworld_as_default.war Web application that is located in the
<WORK_HOME>/lab4 directory to server1.

Note: Do not forget to activate the changes and start the application.

3.4 Verify the default Web application configuration by browsing to http://localhost:7003.

Note: You do not need to specify the application root /helloworld in the requested URL
any more.

Undeploy the helloworld_as_default.war Web application using the Administration
Console.

4.1 Navigate to base_domain > Deployments. Lock the console.

4.2 In the Deployments table, click helloworld_as_default. The settings for
helloworld_as_default appears. Click the Targets tab, deselect the check box for
the server1 target, and then click Save. Under Message, you should get a
confirmation that your settings were saved successfully.

4.3 Activate your changes.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
19
Solution: Deploying/Undeploying Web Applications
(continued)

4.4 Verify that the Web application was indeed undeployed by browsing to
http://localhost:7003.

You should get an error, Error 404 Not Found, when you do this.

Note: If you use the same browser window to request the Web application, browser
caching may result in pages being served even after the application itself is undeployed.
You can clear the browser cache for Firefox by selecting Edit > Preferences > Privacy >
Cache Options from the Menu bar and clicking Clear Cache Now. Reload the page.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
20

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
21
Lab 5



Using a Deployment Plan




After completing this practice, you should be able to:
Create deployment plans
Deploy enterprise applications along with the deployment plan
Describe the directory structure of an exploded enterprise application for its successful
deployment


Sometimes, it is necessary to deploy applications multiple times and in different types of
environments. Instead of having to configure the deployment information each time, it would be
easier to package that information with the application. Therefore, the user creates the
deployment plans for an enterprise application and creates a proper directory structure for the
successful deployment of enterprise applications.



The user manually creates an initial deployment plan for an enterprise application that resides
outside the application archive and configures an application for deployment to a specific Oracle
WebLogic Server environment. The deployment plan helps the administrator to easily modify an
applications WebLogic Server configuration for deployment into multiple, differing WebLogic
Server environments without modifying the deployment descriptor files that are included in the
application archive. The user creates a proper directory structure for the successful deployment of
enterprise applications that are packaged with the deployment plan. See Figure 8.


F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
22
Basic Instructions

1. Create the folder C:\studentWLS103\work\lab5\plan


2. Use weblogic.PlanGenerator to create a plan entitled plan.xml for the
helloworld application. Open a command prompt and change to the C:\work
directory. Execute the following command:

java weblogic.PlanGenerator all root lab5


Navigate to the C:/work/lab5/plan directory and open
plan.xml using a text editor.
Set / as a value for
<variable><name>WeblogicWebApp_ContextRoots_xxxxxxxxx
xxxxx.
Remove the attribute xsi:nil="true" from the <value> tag, so that it
looks like the following:
<variable>
<name>WeblogicWebApp_ContextRoots_
xxxxxxxxxxxxxx </name>
<value>/</value>
</variable>
In the area <variable-
assignment><name>WeblogicWebApp_ContextRoots_
xxxxxxxxxxxxxx
add the following line: <operation>replace</operation>,
so that it looks like the following:
<variable-assignment>
<name>WeblogicWebApp_ContextRoots_ xxxxxxxxxxxxxx
</name>
<xpath>/weblogic-web-app/context-root</xpath>
<operation>replace</operation>
</variable-assignment>

3. Redeploy the application with the plan in the Administration Console.

5. View the deployed application.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
23
Solution: Using a Deployment Plan
In this practice, you create a deployment plan, and then deploy an application using this
plan.


Set up the exercise.

1.1 Create the folder C:\studentWLSS103\work\lab5\plan


Deploy the helloworld application


2.1 In the Administration Console, navigate to base_domain > Deployments. Lock
the console, if necessary.

2.2 Click Install in the right pane and browse to the
C:\studentWLSS103\work\lab5\app directory.
Select helloworld.war and click Next.

2.3 On the Install Application Assistant page, select Install this deployment as an
application and click Next.

2.4 Target the application to server1. Click Next.

2.5 On the Optional Settings page, enter HRApp as the name and select Copy this
application onto every target for me under the Source Accessibility section. Click
Finish and Activate the changes.

2.6 Navigate to base_domain > Deployments and select the check box for the
helloworld application. Click Start > Servicing all Requests.

2.7 Point your browser to http://localhost:7003/helloworld.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
24
Solution: Using a Deployment Plan (continued)

Use weblogic.PlanGenerator to create a plan plan.xml.



3.1 Change to the C:\studentWLSS103\work\lab5\plan directory.
3.2 Enter the following command:

java weblogic.PlanGenerator all root lab5

PlanGenerator is a utility for creating a deployment plan template based on the
standard descriptors included in an application. The resulting plan (-plan option) will
describe the application structure, identify all deployment descriptors, and will export a
subset of the applications configurable properties.

By default, the plan exports only application dependencies. This can be overridden with
any one of the following:
-declarations: Export resources defined by the application
-configurables: Export non-resource-oriented configurable properties
-dynamics: Export properties that may be changed in a running application
-all: Export all changeable properties
-none: Export no properties

3.3 Navigate to the C:\studentWLSS103\work\lab5\plan directory and open
plan.xml using a text editor.

3.4 Set / as a value for
<variable><name>WeblogicWebApp_ContextRoots_xxxxxxxxx</name></variable>.


3.5 Remove the attribute xsi:nil="true" from the <value> tag, so that it appears thus:
<variable>
<name>WeblogicWebApp_ContextRoots_xxxxxxxxxx</name>
<value>/</value>
</variable>

3.6 In the following area:
<variable-assignment>
<name>WeblogicWebApp_ContextRoots_xxxxxxxxxxxx </name>
Add the following line:
<operation>replace</operation>

So that it appears thus:
<variable-assignment>
<name> WeblogicWebApp_ContextRoots_xxxxxxxxxxxx </name>
<xpath>/weblogic-web-app/context-root</xpath>
<operation>replace</operation>
</variable-assignment> F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
25
Solution: Using a Deployment Plan (continued)

Redeploy the application with the plan in the Administration Console.

4.1 In the Administration Console, navigate to base_domain > Deployments. Lock
the console.

4.2 Select helloworld and click Update.

4.3 Click Change Path next to Deployment Plan Path.

4.4 Select C:\studentWLSS103\work\lab5\plan.
Select plan.xml and click Next.

4.5 Select Redeploy this application using the following deployment files (if not
selected). Click Next, and then click Finish. Click Activate changes.

View the deployed application.

5.1 Point your browser to http://localhost:7003/.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
26

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
27
Lab 6: Production Redeployment




After completing this exercise, you should be able to describe:
Production Redeployment
The importance of versioning the enterprise applications that are deployed to Oracle
WebLogic Server
The importance and advantages in using Production Redeployment


The user gets to deploy the first version of an application and view the application. Thereafter, the
user redeploys the second version of the same application, which is modified a bit, and views this
version of the application. The old client, if not yet finished with using the application, still has
access to the first version of the application, whereas the new clients get connected to the second
version of the application. When the first version of the application is no longer in use by a client,
the state of the first version of the application is retired and that version of the application
becomes unavailable.



Using the Production Redeployment strategy, users can experience how to use WebLogic Server
to redeploy a new version of a production application without interrupting the availability of the
application to new client requests. Thus, the new clients get connected to the new version of the
application, and the previous version of the application, which is still in use by the older clients,
gets retired after the client disconnects.


F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
28
Basic Instructions


1. Verify that both v1 and v2 are in the C:\studentWLSS103\work\lab6 directory.
2. Deploy the helloversion application that is stored in the
C:\studentWLSS103\work\lab6\v1 directory such that the version number for that
application is v1.0.

3. View the deployed application, v1.0.

4. The State of the deployed application v1 should be Active.

5. Deploy the helloversion application from the C:\studentWLSS103\work\lab6\v2
directory such that the version number for that application is v2.0.

6. After you redeploy the application as v2.0, the State of the application v1.0 becomes
stop running (and later become retired) and the State of the newly deployed application
v2 is Active.

7. View the deployed application v2.0 for changes (the text displayed is v2.0). All the new
clients get connected to v2.0 of the application. When v1.0 of the application is no
longer in use by a client, the State of the application becomes Retired.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
29
Solution: Production Redeployment
In this practice, you configure production redeployment for two versions of an
application.




Copy the helloversion application.

1.1 Verify that both v1 and v2 are in the C:\studentWLSS103\work\lab6 directory.



Deploy the helloversion application stored in the C:\studentWLSS103\work\lab6\v1
directory such that the version number for that application is v1.0.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
30
Practice 6-2: Production Redeployment (continued)
2.1 Open the command prompt and navigate to the
C:\studentWLSS103\work\lab6\v1 directory. Enter the following to deploy the
application:

java weblogic.Deployer -adminurl t3://localhost:7001
-user weblogic -password weblogic1 -deploy -name helloversion
source helloversion.war -targets server1 -stage -appversion v1.0

View the deployed application v1.

3.1 Point your browser to http://localhost:7001/helloversion.
The text shown should be v1.0

Note: Do not close this browser because it is required to show further results.

State of the deployed application v1.0 should be Active.

4.1 Click Deployments under the base_domain domain structure in the left pane of the
Administration Console. In the right pane on the Summary of Deployments page, check
to see whether the State of the helloversion (v1.0) application is Active. (Note:
You may see a warning message under the Health column.)

Deploy the helloversion application stored in the C:\studentWLSS103\work\lab6\v2
directory such that the version number for that application is v2.0.

5.1 In the command prompt, navigate to the C:\studentWLSS103\work\lab6\v2
directory. Enter the following to deploy the helloversion.war application:


java weblogic.Deployer -adminurl t3://localhost:7001
-user weblogic -password weblogic1 -deploy -name helloversion
source helloversion.war -targets server1 -stage -appversion v2.0

After redeploying the application as v2, the State of application v1.0 becomes stop
running and the State of the newly deployed application v2.0 is Active.

6.1 Click Deployments under the base_domain domain structure in the left pane of the
Administration Console. In the right pane on the Summary of Deployments page, check
to see whether the State of the: helloversion(v1.0)application is stop running
and the helloversion (v2.0) application is Active.(Note: You may see a warning
message under the Health column.)

6.2 Display the browser window that you opened in step 3.1.

Note: v1.0.

View the deployed application v2.0 for changes.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
31
Solution: Production Redeployment (continued)

9.1 Open up a new browser from your neighbours PC and point to your weblogic
server
E.g. http://<IP>:7003/helloversion/

Note: The version should be v2.0.



All the new clients get connected to v2.0 of the application. When v1.0 of the
application is no longer in use by a client, the State of the application becomes Retired.
(It may take a while for the state to change.)
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
32

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
33
Lab 7

Configuring the JMS Servers and Destinations




After completing this practice, you should be able to get hands-on experience with configuring
and monitoring J ava Message Service (J MS) queues and topics.

A J MS server implements the J MS infrastructure on a WebLogic Server. Destinations
(queues or topics) are targeted to a WebLogic server when the J MS server is targeted to
the WebLogic server.

In this exercise, you configure a J MS server myJMSServer, a queue myQueue, and a
topic myTopic. You then post messages to the queue and topic, and monitor them in the
Administration Console. For reference, see the following figure.

Currently, you do not have any consumers; you simply post the messages and get familiar
with monitoring the message statistics in the Administration Console.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
34
Basic Instructions

1. Configure a JMS server with the following specifications:

Name: myJMSServer
Persistent Store: (none)

2. Configure a JMS module, and add a queue and topic to the JMS module, according to the
following specifications:

JMS Module
Name: myModule
Descriptor File Name: myModule
Target: server1

Subdeployment
Subdeployment Name: server1SubDeployment
Targets: myJMSServer

Queue
Name: myQueue
JNDI Name: myQueue
Template: None
Target: myJMSServer

Topic
Name: myTopic
JNDI Name: myTopic
Template: None
Target: myJMSServer

3. Deploy the messaging.war Web application, which allows you to post messages to the
queue or the topic.

4. Verify that the Web application is deployed correctly by navigating to
http://localhost:7003/messaging and posting messages to either the queue or the topic
using the deployed Web application.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
35
Practice 7-1: Configuring the J MS Servers and Destinations
In this practice, you configure the J MS server and J MS module, and add a queue and
topic to the module.



Configure a JMS server.

2.1 Ensure that AdminServer, and server1 are running.

2.2 Navigate to base_domain > Services > Messaging > JMS Servers. Lock the console.

2.3 Click New under the JMS Servers table and specify the following properties:

Name: myJMSServer
Persistent Store: (none)

2.4 Click Next and target the JMS server to the server1 Managed Server. Click Finish.

2.5 Activate your changes.

Configure a JMS module, and add a queue and topic to the JMS module.

3.1 Navigate to base_domain > Services > Messaging > JMS Modules. Lock the console,
if necessary.

3.2 Click New under the JMS Modules table and specify the following properties:

Name: myModule
Descriptor File Name: myModule

3.3 Click Next and target the module to the server1 Managed Server. Click Next and
select the following:

Would you like to add resources to this JMS system module?

3.4 Click Finish.

3.5 On the Settings for myModule page, click the Subdeployments tab. Under the
Subdeployments table, click New to create a subdeployment with the following
specifications:

Subdeployment Name: server1SubDeployment

Click Next.

3.6 On the Targets page, select myJMSServer as the target under the JMS Servers
table. Click Finish.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
36
Practice 7-1: Configuring the J MS Servers and Destinations
(continued)

3.7 Click the Configuration tab.

3.8 On the Settings for myModule page, under the Summary of Resources table, click
New to configure a new JMS queue for the JMS module.

3.9 On the Create a New JMS System Module Resource page, under Choose the type of
resource you want to create, select Queue.

3.10 Click Next.

3.11 In JMS Destination Properties, specify the following parameters:

Name: myQueue
JNDI Name: myQueue
Template: None

3.12 Click Next.

3.13 Select server1SubDeployment from the subdeployments list. Click Finish.

3.14 On the Settings for myModule page, under the Summary of Resources table, click
New to configure a new JMS topic for the JMS module.

3.15 On the Create a New JMS System Module Resource page, under Choose the type of
resource you want to create, select Topic.

3.16 Click Next.

3.17 In JMS Destination Properties, specify the following parameters:

Name: myTopic
JNDI Name: myTopic
Template: None

3.18 Click Next.

3.19 Select server1SubDeployment from the subdeployments list. Click Finish.

3.20 Activate the changes.

You should be able to see the JNDI entries, called myQueue and
myTopic, on the server1 Managed Server.

Deploy the Web application messaging.war, which allows you to post messages to the
queue or topic.

4.1 Navigate to the C:\studentWLSS103\work\lab7 directory, locate the
messaging.war file.

4.2 Navigate to base_domain > Deployments. Lock the console.

4.3 Select Install, navigate to C:\studentWLSS103\work\lab7, and select
messaging.war. Click Next, accept all the defaults, and click Next again. Target the
application to server1. Click Next and accept all the defaults. Click Finish (when
possible).
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
37
Practice 7-1: Configuring the J MS Servers and Destinations
(continued)

4.4 Activate your changes.

4.5 Start the application by selecting the check box against the application name under the
Deployments table. Click Start and select Servicing all requests.

Verify that the Web application is deployed correctly.

5.1 If not already open, open a Web browser and navigate to
http://localhost:7003/messaging.

5.2 Using the application, post several messages to the standard queue and to the topic, not
to the distributed queue.

5.3 Use the Administration Console to view the number of messages that have been posted
into each of the destinations. Navigate to base_domain > Services > Messaging >
JMS Modules. In the JMS Modules table, click myModule. On the Summary of
Resources page, click myQueue, and then click the Monitoring tab.

Customize this table to show the Messages Total column. The Messages Total column
shows you the number of messages that have been sent to myQueue. Repeat these
steps to view the number to messages sent to myTopic. (Observe the Messages total
count.)

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
38

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
39
Lab 7b



Configuring Data Sources





After completing this exercise, you should be able to:
Create a J DBC data source
Locate a J DBC data source in a servers J NDI tree




A DataSource object enables a J DBC client to obtain a DBMS connection from a J DBC pool.
The connection pool within a J DBC data source contains a group of J DBC connections that
applications reserve, use, and then return to the pool. The connection pool and the connections
within it are created when the connection pool is registered, usually when starting up Oracle
WebLogic Server or when deploying the data source to a new target. In this lab, you create a
myDS data source to connect to HRDatabase.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
40

Basic Instructions

2. Create a DataSource with the following specifications:

Name: myDS
JNDI Name: myDS
Database Type: Oracle
Database Driver: *Oracles Driver(Thin) for instance connections;
Versions:9.0.1,9.2.0,10,11
Database Name: xe
Host Name: 10.11.0.92
Port: 1052
Database User Name: testuser
Password: testing1
Initial Capacity: 1
Maximum Capacity: 2
Capacity Increment: 1
Login Delay: 1
Target: server1

3. Verify the DataSource by deploying a prepackaged testds.war Web application and
navigating to http://localhost:7001/testds/testdatasource.jsp to test the datasource.


F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
41
Practice 7b-1: Configuring Data Sources
In this practice, you create and validate a new DataSource.



Create a DataSource object.

2.1 Start AdminServer and the server1 Managed Server if they are not already running.

2.2 If not already open, open a Web browser and navigate to http://localhost:7001/console.
Log in as:

Username: weblogic
Password: weblogic1

2.3 Navigate to base_domain > Services > JDBC > Data Sources. Lock the console.

2.4 On the Summary of JDBC Data Sources page, lock the console and click New under the
Data Sources table. Specify the following properties for configuring a JDBC data source:

Name: myDS
JNDI Name: myDS
Database Type: Oracle
Database Driver: *Oracles Driver(Thin) for instance connections;
Versions:9.0.1,9.2.0,10,11


Note: Do not select the Thin XA driver.

2.5 Click Next.

2.6 On the Transaction Options page, retain the default options and click Next.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
42
Practice 7b-1: Configuring Data Sources (continued)

2.7 Define the following connection properties:

Database Name: xe
Host Name: 10.11.0.92
Port: 1521
Database User Name: testuser
Password: testing1

2.8 Click Next.

2.9 Click Test Configuration to check if the connection to the database is working, and then
click Next.

2.10 Target the server1 Managed Server and click Finish.

2.11 Click myDS under the Data Sources table on the Summary of JDBC Data
Sources page.

2.12 Click the Configuration > Connection Pool tab. Specify the following parameters:

Initial Capacity: 1
Maximum Capacity: 2
Capacity Increment: 1

2.13 Save and activate your changes.

2.14 Check the JNDI tree of the server1 Managed Server to make sure that the data source
is deployed. Look for a JNDI entry called myDS.

Verify the DataSource by deploying a prepackaged testds.war Web application.

3.1 Navigate to the <LAB_HOME>/exercise directory, locate the testds.war file, and
copy it to the <WORK_HOME>/applications directory.

3.2 Navigate to base_domain > Deployments. Lock the console.

3.3 Select Install, navigate to <WORK_HOME>/applications, and select testds.war.

3.4 Make sure that you opt to Install this deployment as an application, target the
application to server1, and select Copy this application onto every target for me
for Source accessibility on the Optional Settings page. Click Finish.

3.5 Activate your changes, and then start the application.

3.6 Open a Web browser and navigate to http://localhost:7003/testds/testdatasource.jsp to
test the data source. Use the Test Data Source button to retrieve data from the xe
database.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
43

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
44
Lab 8: Configuring SSL


<WORK_HOME> = C:\studentWLSS103\work
<BASE_HOME> = C:\Oracle\Middleware\user_projects

After completing this exercise, you should be able to:
Use keytool to generate an identity keystore that contains a private key and a self-signed
public certificate
Configure keystores
Configure secure sockets layer (SSL)

Many applications need the security of communicating over the secure sockets layer
(SSL). This provides secure communications between the server and the client, or
between two servers. In this lab, you configure SSL and the keystores for the server1
Managed Server in the base_domain domain.


Table 5: Identity Key and Certificate Design Specifications

Identity Key and Certificate
X.500 Distinguished Name: "CN=localhost, OU=Weblogic Workshop, O=Weblogic,
C=US"
Private key alias: mykey
Private key password: mykeypass
Validity duration: 365 days

Encryption strength:

Algorithm (-keyalg): RSA

Size (-keysize): 512-bit

CSR filename: my_cert_request.pem


Table 6: Identity Keystore Design Specifications

Identity Keystore

Keystore filename my_identity.jks
Keystore directory $WEBLOGIC_DOMAIN
Keystore password mystorepass
Keystore type JKS

Table 7: Trust Keystore Design Specifications

Trust Keystore

Keystore filename cacerts
Keystore directory $JAVA_HOME/jre/lib
Keystore password changeit
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
45
Basic Instructions

1. Generate a key, a self-signed certificate, and an identity keystore:

Run the Java keytool -genkey command. For example:
keytool genkey v alias mykey keyalg RSA keysize 512
-dname "CN=localhost, OU=Weblogic
Workshop, O=Weblogic, C=US"
-keypass mykeypass
-validity 365
-keystore my_identity.jks
-storepass mystorepass

Copy the my_identity.jks file from <WORK_HOME>/security to the
<BASE_HOME>/domains/base_domain directory.

2. Generate a CSR:

Run the Java keytool -certreq utility. For example:
keytool certreq v alias mykey file my_cert_request.pem
-keypass mykeypass storepass mystorepass
-keystore my_identity.jks

Copy the my_cert_request.pem file from <WORK_HOME>/security to the
<BASE_HOME>/domains/base_domain directory.

3. Configure the keystores by specifying the following properties from the WebLogic
Administrative Console:

Keystores: Custom Identity and Java Standard Trust
Custom Identity Keystore: my_identity.jks
Custom Identity Keystore Type: JKS
Custom Identity Keystore Passphrase: mystorepass
Java Standard Trust Keystore Passphrase: changeit

4. Configure SSL by specifying the following properties:

Identity and Trust Locations: Keystores
Private Key Alias: mykey
Private Key Passphrase: mykeypass

5. Test the SSL setup.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
46
Solution: Configuring SSL
In this practice, you perform all the steps to configure SSL in an Oracle WebLogic Server
environment.

Generate a key, a self-signed certificate, and an identity keystore.

2.1 Navigate to the <WORK_HOME> directory and create a new directory by name security.

2.2 Open a command prompt (if not already open).

2.3 Change to the <WORK_HOME>/security directory.

2.4 Run the Java keytool -genkey command.
Use the information in Table 5 and Table 6 to supply the keytool command arguments,
for example:
C:\Oracle\Middleware\jdk160_14_R27.6.5-32\bin\keytool.exe
genkey v alias mykey keyalg RSA keysize 512
-dname "CN=localhost, OU=Weblogic
Workshop, O=Weblogic, C=US"
-keypass mykeypass
-validity 365
-keystore my_identity.jks
-storepass mystorepass

The key and certificate are generated and stored in a keystore.

Copy the my_identity.jks file from <WORK_HOME>/security to the
<BASE_HOME>/domains/base_domain directory.


Generate a Certificate Signing Request (CSR).

3.1 Open a command (if not already open).

3.2 Change to the <WORK_HOME>/security directory.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
47
Solution: Configuring SSL (continued)
3.3 Run the Java keytool -certreq utility. Use the information in Table 5 and Table 6 to
supply the keytool command arguments, for example:
C:\Oracle\Middleware\jdk160_14_R27.6.5-32\bin\keytool.exe
certreq v alias mykey file my_cert_request.pem
-keypass mykeypass storepass mystorepass
-keystore my_identity.jks
A CSR is generated.

Copy the my_cert_request.pem file from <WORK_HOME>/security to the
<BASE_HOME>/domains/base_domain directory.

Configure the keystores.

4.1 Make sure that AdminServer and server1 are running.

4.2 If not already open, open a Web browser and navigate to http://localhost:7001/console.
Log in as:

Username: weblogic
Password: weblogic1

4.3 Navigate to base_domain > Environment > Servers > server1 > Configuration >
Keystores. Lock the console.

4.4 On the Keystores page, specify the following properties:

Keystores: Custom Identity and Java Standard Trust
Custom Identity Keystore: my_identity.jks
Custom Identity Keystore Type: JKS
Custom Identity Keystore Passphrase: mystorepass
Java Standard Trust Keystore Passphrase: changeit

4.5 Save the changes.

Configure SSL.

5.1 Go to base_domain > Environment > Servers > server1 > Configuration > SSL.

5.2 On the SSL page, specify the following properties:

Identity and Trust Locations: Keystores
Private Key Alias: mykey
Private Key Passphrase: mykeypass

5.3 Save the changes.

5.4 Navigate to base_domain > Environment > Servers > server1 > Configuration >
General. Verify that the check box next to SSL Listen Port Enabled is selected and
that the SSL Listen Port is 7004.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
48
Solution: Configuring SSL (continued)
5.5 Activate the changes and restart the server1 Managed Server.

Test the SSL setup.

6.1 Open a browser window and navigate to https://localhost:7004/helloworld.

You should see a warning, The certificate issued by your server is not signed by a
trusted authority, because in this lab, you use a self-signed digital certificate. Accept
the certificate (the description may vary from one browser to another). The
helloworld application should then open up in your browser.


F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
49
Lab 9



Creating a Basic Cluster

<WORK_HOME> = C:\studentWLSS103\work
<BASE_HOME> = C:\Oracle\Middleware\user_projects

After completing this practice, you should be able to:
Create a cluster of Managed Servers
Start clustered servers

In this lab, you create a cluster of three servers, server1, server2, and server3.


base_domain
myCluster
machine1





machine2





server1 server2 server3













Figure 10: Cluster Architecture
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
50
Basic Instructions

1. If they are running, shut down the server1, server2, and server3 Managed Servers.
If it is not open, start a Web browser and navigate to http://localhost:7001/console. Log in
as:

Username: weblogic
Password: weblogic1
Create a new cluster with the following properties:
Name: myCluster
Multicast Address: 239.192.0.0 (default)
Multicast Port: For example, a unique number (Check with your instructor.)
Servers: server1, server2, server3
2. Start server1, server2, and server3. Watch each server as it tries to synchronize
with other servers in the cluster and as it finally joins the cluster. During startup of the
servers, if prompted, enter the following:

Username: weblogic
Password: weblogic1

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
51
Configuring Proxy Servers


After completing this exercise, you should be able to:
Set up HTTPClusterServlet in a WebLogic Server to proxy requests to a cluster




You have created your myCluster but you still have not finished setting up the environment, so
the application requests are sent to different servers in the cluster. In this lab, you create a proxy
servers: HTTPClusterServlet in a new WebLogic Server called proxyServer
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
52






Specifications
Figure 11 presents the cluster with the HTTPClusterServlet proxy architecture.











base_domain


proxyServer (with
HTTPClusterServlet)





myCluster

machine1 machine2





server1 server2 server3














Figure 11: HTTPClusterServlet Proxy Architecture

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
53
Basic Instructions

1. Create the WebLogic proxy server with the following properties:

Server Name: proxyServer
Server Listen Address: localhost
Server Listen Port: 7009
Standalone Server: True

Start the proxy server.

2. Configure the HTTPClusterServlet in /WEB-INF/web.xml. Add the <init-param>
element that tells the servlet what servers are in the cluster. Add the <servlet-
mapping> elements that map HTTPClusterServlet
to any request for JSPs, HTML, and HTM pages plus anything that is not recognized.

3. Using /WEB-INF/weblogic.xml, set the proxy application as the default Web
application for the proxy server.

4. Package the proxy application into proxyApp.war and copy it to
<WORK_HOME>/applications. Deploy proxyApp.war to proxyServer.

5. Deploy the application browsestore. Open a Web browser and navigate to the
browsestore application on the proxy server at http://localhost:7009/browsestore.
Test the proxy server by browsing the application and checking the server console
windows to see which server is handling the request. You should see different servers
handling each request.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
54
Solution: Creating a Basic Cluster
In this practice, you create and start a cluster.



Create a cluster.

1.1 If already running, shut down server1, server2 and server3 Managed Servers.

1.2 If it is not already open, start a Web browser and navigate to
http://localhost:7001/console. Log in as:

Username: weblogic
Password: weblogic1

1.3 Navigate to base_domain > Environment > Clusters. Lock the console, if necessary.

1.4 Create a new cluster with the following properties:

Name: myCluster
Messaging Mode: Multicast
Multicast Address: 239.192.0.0 (default)
Multicast Port: For example, 7011 (Check with your instructor.)
Each student must use a unique port number.

Click OK.

1.5 Return to myCluster and click the Configuration > Servers tab.

1.6 Add the existing servers server1, server2 and server3 to the cluster.

1.7 Activate your changes.

1.8 Navigate to base_domain > Environment > Servers and view the list of servers.
Note that server1, server2, and server3 are now part of myCluster.

Start the clustered servers.

2.1 Using a command prompt, navigate to
<BASE_HOME>/domains/base_domain/bin.

2.2 Start the server1 server by entering the following in the prompt:


startManagedWebLogic.cmd server1
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
55
Practice 9-1: Creating a Basic Cluster (continued)

2.3 If you are prompted, enter the following:

Username: weblogic
Password: weblogic1

2.4 Watch the server start up in the prompt window. At some point, you should see it start
listening for cluster announcement and waiting to synchronize with other servers in the
cluster. Because the other servers have not started yet, there is nothing for it to
synchronize with yet.

<Notice> <Cluster> <BEA-000138> <Listening for announcements from
cluster myCluster on 239.192.0.0:7011.>

<Notice> <Cluster> <BEA-000133> <Waiting to synchronize with
other running members of myCluster.>

2.5 Finally, you should see that it has successfully joined the cluster. You see something like:

<Notice> <Cluster> <BEA-000102> <Joining cluster
myCluster on 239.192.0.0:7011>

2.6 Start the server2 server by entering the following in the prompt window:


startManagedWebLogic.cmd server2

2.7 If you are prompted, enter the following:

Username: weblogic
Password: weblogic1

2.8 Watch the server start up in the prompt window. Because one of the servers in the cluster
has started up, server2 synchronizes with server1 and downloads the cluster JNDI
tree.

<Notice> <Cluster> <BEA-000133> <Waiting to synchronize with
other running members of myCluster.>

2.9 Finally, start the server3 server, watch it synchronize with the other servers in the
cluster, and finally join the cluster.

F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
56
Solution: Configuring Proxy Servers
In this practice, you create and configure a proxy server.


Set up the exercise.

1.1 Download the application browsestore.war
1.2 Deploy the application browsestore to myCluster.



Create the WebLogic proxy server.

2.1 If it is not already open, start a Web browser and navigate to
http://localhost:7001/console.
Log in as:

Username: weblogic
Password: weblogic1

2.2 Navigate to base_domain > Environment > Servers. Lock the console, if necessary.

2.3 Create a new server with the following properties:

Server Name: proxyServer
Server Listen Address: localhost
Server Listen Port: 7009
Standalone Server: True

Click Next.

2.4 Click Finish. Activate your changes.

2.5 Open a command prompt. Navigate to the
<BASE_HOME>/domains/base_domain/bin directory.

2.6 Start the proxyServer server by entering the following in the prompt. (Use
weblogic/weblogic1 as username/password.):


startManagedWebLogic.cmd proxyServer

Configure the HTTPClusterServlet.

3.1 Open <WORK_HOME>/applications/proxyApp/WEB-INF/web.xml in a text editor.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
57
Solution: Configuring Proxy Servers (continued)
3.2 In the <servlet> element, add the HTTPClusterServlet.

<servlet-name>HttpClusterServlet</servlet-name>
<servlet-
class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>

3.3 After the <servlet-class> element, add the <init-param> element that tells the
servlet what servers are in the cluster.

<init-param>
<param-name>WebLogicCluster</param-name>
<param-
value>localhost:7003|localhost:7005|localhost:7007</param-value>
</init-param>

3.4 After </servlet>, add the <servlet-mapping> elements that map
HTTPClusterServlet to any request for JSPs, HTML, and HTM pages plus anything
that is not recognized.

<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>

Alternatively, you could copy and paste the elements from
Z:/exercise/web.txt.

3.5 Save and close the file.

Set HTTPClusterServlet as the default Web application on the proxy server.

4.1 Open <WORK_HOME>/lab10/proxyApp/WEB-INF/weblogic.xml in a text editor.

4.2 Within the <weblogic-web-app> element, add the <context-root> element, which
makes this the default Web application for proxyServer.

<context-root>/</context-root>

4.3 Save and close the file.
F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
58
Solution: Configuring Proxy Servers (continued)

Package the proxy application and deploy to the proxy server.

5.1 In the prompt window, navigate to <WORK_HOME>/applications/proxyApp
and package the application using the following command:

C:\Oracle\Middleware\jdk160_14_R27.6.5-32\bin\jar cf
../proxyApp.war *



5.2 Deploy <WORK_HOME>/applications/proxyApp.war to the proxyServer.
Activate your changes and start the application.

Test the WebLogic proxy server.

6.1 Restore the server1, server2, and server3 server windows and arrange them
so that you can see all three simultaneously.

6.2 Open a Web browser and navigate to the browsestore application that is
accessed through the proxy server at http://localhost:7009/browsestore.

6.3 Check the server windows to see which server received the request.

6.4 Click the Browse Store link. Check the server windows to see which server
received the request.

6.5 Select a category and retrieve the items. Return to the home page, select another
category, and retrieve the items again. Check the server windows to see which
server received the request. (Try open a different browser to access the
application through the proxy server at http://localhost:7009/browsestore.)


F
o
r

H
o
n
g

K
o
n
g

H
o
s
p
i
t
a
l

A
u
t
h
o
r
i
t
y
59