WLS Admin 11gR1 Lab Guide

WebLogic Server 11g Workshop
Lab Guide
WLS Basic Setup & Admin 11gR1 Workshop
Contents
Lab Guide
WLS Admin 11gR1 Workshop
Contents
Lab Overview
Lab Pre-Requisites
Lab 1 Product Installation
Lab 2 Create a WebLogic Domain
Lab 3 WLST
Lab 4 Troubleshooting
Lab 5 Monitoring
Lab 6 JDeveloper and ADF
Appendix A Command-Line Installation
Appendix B Console Mode Domain
Copyright 2009, Oracle. All rights reserved.
1
1
1
2
2
3
9
28
37
43
57
78
79
-1-
Lab Overview
This course should work on any Windows machine or image that has free hard disk
space and around 2G+ of RAM. If you use the image that is available with this
workshop, the following directories will be used, with the Labs and Installers already
in existence. If you use your own image, simply ensure that these directories are
used. Please refer to the following as directories on this to be used throughout the
rest of the document:
<WLS_HOME> - C:\weblogic
<LAB_HOME> - C:\Labs
<INSTALL> - C:\Labs\Lab1_Install
<DOMAIN_HOME> - C:\weblogic\user_projects\wls_domain
For each lab step, pictures will follow the instruction given.
Lab Pre-Requisites
If you are using the VM Image that ships with this workshop, the following steps are
done for you. If not, you will need to complete these steps using a base Windows
image prior to starting the workshop.
Step 1
In order to complete this workshop, you should download at least the 2nd and 3rd
installers from the table below. The download for WebLogic Server 11gR1 can be
found on the Oracles download site:
http://www.oracle.com/technology/software/products/ias/htdocs/wls_main.html
There are multiple possibilities for installation file depending on the track you decide
to take. The following table lists some of the choices:
Install Type
Base WebLogic Over Network
Base WebLogic
WebLogic + JDeveloper 11g
Installer File
net_oepe11_wls1031.exe
oepe11_wls1031.exe
jdevstudio11111install.exe
Please download the 2nd and 3rd ones listed above. Well start with the 2nd installer
from the table above, and then run the 3rd one during Lab 6.
Step 2
Uncompress the labs from the zip file and ensure they exist under the <LAB_HOME>
directory. Under this directory, you should have a couple of files and directories for
most of the labs.
-2-
Step 3
Finally, you will need Oracle XE running on port 1521. You can do a basic install and
simply create a user call WLS with a password of WLS
Lab 1 Product Installation

1. Locate WebLogic installer file within <INSTALL>. You can double click it to run
within the GUI. For these screen shots, we show the base package installer
for WebLogic.
2. Follow these screen shots to select the installation directory, and install the
product.
-3-
-4-
-5-
-6-
3. Verify that the installation completed, by looking at the file system within the
<INSTALL> directory
-7-
-8-
Lab 2 Create a WebLogic Domain

This lab will create a domain in 3 different ways. As with the product installation, it
can happen either through a GUI or from a command line tool. Well use the GUI
here, but the command line tool will do everything you can do with the GUI. Appendix
B shows you how to invoke the domain wizard from the command line. For this lab,
well create 2 domains, one from a domain template we will create in a later lab (precreated for this lab), and again from the standard domain configuration tool. By doing
the one from the basic tool, well start vanilla and use Lab 3 to create a customized
domain we can run with.
Activity 1 Domain From Template
1. Using the WebLogic Domain Configuration wizard, well complete this and the
next activity. First, well use a pre-packaged domain template (you will create
this during Lab 3), 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 we will use the GUI here, this is entirely scriptable, and allows for
cross-platform work.
TIP: As seen in the tooltip above, the executable can run from a prompt and is
located at
<WLS_INSTALL>/wlserver_10.3/common/bin/config.cmd
2. You will want to create a new domain, base it on a template, and select the
<LAB_HOME>\Lab2_Domains\wls_domain.jar template.
-9-
- 10 -
3. Follow the prompts on each screen, leaving the defaults by clicking <enter>.
Not all screens you will see are shown below. Stop when you get to the screen
(last screen below) that offers you to customize pre-configured settings.
- 11 -
- 12 -
- 13 -
4. Simply select the defaults here on each screen, but notice that a connection
pool and application are already included. Complete the activity by following
the screens and completing the domain. At the confirmation screen, select the
option to start the domain for you.
- 14 -
- 15 -
5. Verify that the domain starts by running the domain start script. Look for
RUNNING Mode and the listen port as verification that the server started ok.
6. Using a browser, visit the WLS console, and verify that you can log in as
weblogic/weblogic1. Note that you can use localhost or your hostname as
part of the URL, and this is entirely configurable.
- 16 -
- 17 -
Activity 2 Domain From Scratch

7. Stop WebLogic that you started from the previous activity. 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:
TIP: After hitting <enter> and waiting a moment, you will see the server shut
down. Note that the first time WLST is invoked after installation, it is slow, but
that subsequent invocations of the stop script will be faster.
- 18 -
8. Delete the entire <DOMAIN_HOME> directory from Windows Explorer.

Remember to make sure you have no open command prompts or
processes running from this directory. Otherwise it will not delete properly.
- 19 -
9. In order to start from scratch, well create a vanilla WebLogic domain. This
time, instead of using a packaged domain template (like we did in Activity 1),
well configure the domain as new. Run the same command as step 1, and
follow the prompts, making sure to enter the fields as shown:
Field
Domain Name
WL Username
WL Password
Value
wls_domain
weblogic
weblogic1
NOTE: Appendix B will do this exact step using the command line. This is so
you can see that it is the same set of steps without the GUI.
- 20 -
- 21 -
10. For the JDK, you are free to choose, as either will work ok. For this lab, select
JRockit. Proceed until the confirmation screen.
- 22 -
- 23 -
11. Before finishing the installer, click the check box to start the Admin Server, as
this will save time in navigating to the right location and starting it manually.
- 24 -
12. You should see the command window that WebLogic runs in pop up. To
determine that is done starting, look for RUNNING mode and the correct
listen address above it.
- 25 -
13. Using Firefox, visit the WLS console, and verify that you can log in as
weblogic/weblogic1. Note that you can use localhost or your hostname as
part of the URL, and this is entirely configurable.
- 26 -
TIP: Zip and tar can make domain creation for development even easier. Make
zip or tar files as domains are modified in various states. Remember to delete
<DOMAIN_HOME>/servers/<ServerName>/tmp/* to reduce zip file size if you
started the domain at any point. Although not a lab step, this is how Activity 3 was
created.
Activity 3 Domain via UNZIP
1. Lastly, stop and delete this domain again and simply run the self-extractor
(EXE) to start over. This is essentially the same step as the previous
activities, but will be pre-done for you so that we all have the same starting
point. Simply double-click it and select the default location.
2. To finish the activity and prepare for the next lab, start the domain again either
from a command prompt at <DOMAIN_HOME>, or by double-clicking the
startWebLogic.cmd script from the <DOMAIN_HOME> using Windows
Explorer. See the earlier step to confirm the domain is running.
- 27 -
Lab 3 WLST
This lab does several small tasks to take a basic domain we just created, and turn it
into one that can be deployed in multiple environments. The WebLogic Scripting Tool
(WLST) makes this possible. Weve included a link in the <LAB_HOME> directory to
the tool, but it can be invoked in multiple ways. Refer to Product Documentation for
more detail.
Activity 1 WLST Basics
1. Open a command prompt to c:\Labs. Here you will find a script that will invoke
WLST. This simply points to the actual location within the product installation,
but ease of running the labs, weve put a modified copy here. First run the
script on its own with no arguments:
2. You are now at a prompt in what is called offline mode, which means you
arent connected to a WebLogic server domain. Here you might do things like
create domains, change configuration elements, and build templates for
domains. Lets connect to our running domain from the previous lab to see the
Online mode of WLST. To do this, use the connect() command:
connect('weblogic','weblogic1','t3://localhost:7001')
3. 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
- 28 -
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.
4. Type exit(), as we arent changing anything, or doing anything here just yet. If
time allows, come back to this point and run cd(Servers) as an example to
see this tool operating like a UNIX filesystem.
Activity 2 Script Recording

1. You are welcome to build scripts from scratch, take them from samples and
modify them, or share amongst friends. Another way to create scripts that well
show here is to Record them from the WLS console and modify them. For
example, it may be good to remove specific values from scripts, and make
them parameterized. In order to do this, well open the WLS console in the
browser first.
- 29 -
2. Locate the Change Center at the top left, and lock the console for editing
3. Now click the Script Recording button to start the recording. The console will
show you where it is placing the script you will make. It can be helpful to make
a dry run first in order to show the exact sequence of commands.
- 30 -
4. Here we will make a change to the servers 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.
- 31 -
- 32 -
5. Your script will be in the <DOMAIN_HOME> directory, ending in a .py

extension. Look for something starting with Script that has the current
date. Open it with a text editor.
6. 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 files called:
<LAB_HOME>\Lab3_WLST\WLS_ServerNote.py
<LAB_HOME>\Lab3_WLST\note.properties
You will see that these constitute the changes needed to parameterize the
value, as well as the connection string. Study the differences. Finally, make a
change to the value in the note.properties file, as this will be reflected in the
server configuration.
- 33 -
7. Run the following script from a command prompt at <LAB_HOME>
8. Back in the WLS console, refresh and look for the Servers Notes field to see
the change.
- 34 -
Activity 3 Domain Configuration via WLST

1. Now well finish configuring the domain by running a few WLST scripts, in order
to create a JDBC connection pool, deploy a sample application, and create
global role. Run the following scripts from the command prompt you have at
<LAB_HOME>, and ensure that they complete without errors. Below you see
output from one of the 3 commands.
<LAB_HOME>\Lab3_WLST\WLST_JDBC.py
<LAB_HOME>\Lab3_WLST\WLST_Deploy.py
<LAB_HOME>\Lab3_WLST\WLST_Global_Role.py
- 35 -
TIP: Look at these scripts and start to understand Jython, the WLST syntax,
and some of the types of operations that are possible here.
Activity 4 Package a domain
The final exercise here is to pack the domain into a template, which is what
you will do to preserve settings and changes made throughout configuring of
domains. Packing is also used for creating the incomplete domain directory
that is used on remote managed server machines.
You can run this via the <LAB_HOME>\Lab3_WLST\packdomain script.
Before running it, open it to see that it simply calls the generic WLS pack
command, after setting some parameters for convenience.
- 36 -
Lab 4 Troubleshooting
This lab will focus on a couple of ways to diagnose problems within a WebLogic
Server. There are many ways to do this, and many tools that can help, but for this,
well start small and show a couple simple things that can be done from a command
line to help.
Activity 1 Observe Hung Thread
For the first activity, we will use a very simplistic application that shows signs of
hanging somewhat randomly. If enough threads within WebLogic are hung, the
server could become unresponsive and cause other problems. By using tactics such
as taking thread dumps at intervals when the problem is occurring, the source can
often be identified.
1. Open a command prompt and deploy the FlakyApp application to WebLogic
server. This application has a simple servlet that hangs every once in a
while.
2. From the same prompt prepare to run a thread dump on WebLogic Server.
This is probably the most useful form of immediate debugging. In addition,
Support personnel will almost always require this to help diagnose and fix
issues. We have prepared a WLST script to run the thread dump, and you will
get prepared to run this, by typing the following, without hitting <enter>
- 37 -
TIP: Other ways to perform a thread dump are 1) kill -3 <pid> (UNIX), 2) CtrlBreak (Windows), 3) weblogic.Admin commands, and 4) via the WLS console
3. Open a browser using the URL link from Lab 4. You should see the page load
quickly most of the time, but it is set up to randomly hang. Slowly hit Refresh
until the status bar stays on Waiting for localhost or Transferring.
4. While this is occurring, quickly flip back to your command window and hit
<enter> where you prepared to run the thread dump command. The FlakyApp
gives you 1 minute to do this before the thread completes. In the command
window, you should observe one thread that is stuck at sleep. For this
example, it is trivial. However, this could be a network call, a database call, or
any other java code that is causing an issue. Typically you will need to run
multiple thread dumps in succession at some interval (5s or so) in order to
observe a condition that is outside of normal operation.
- 38 -
5. You now have the source of the issue, along with line numbers, and this is a
great starting point for troubleshooting an issue. Note that the script here also
pushed a file called threaddump.txt out to the local directory.
Activity 2 Diagnostic Image

1. Another useful item to collect when things are not working is a WebLogic
Diagnostic Image. This is a packaged collection of debugging and contextual
- 39 -
information that can be generated easily while a server is misbehaving.

WebLogic also gives users the capability to automatically generate one of
these under detected conditions that administrators can define. In order to
generate one here, well use the script as follows:
In the WebLogic window, you may see this message, which tells us where the
diagnostic image will be generated. Unless configured differently, it will go
inside the servers log directory.
- 40 -
Activity 3 Setting WLS Debug

1. Setting the debug output level for WebLogic is another key part of debugging.
Typically applications and platforms print messages of varying severity or
importance to log files or the console output. With WebLogic, you have full
control over debug information and what is output, and to where. For this
exercise, you will change the debug level for JDBC temporarily, and then
observe the output in the WebLogic log. The first step is to enable the debug
level and debugging parameter for WebLogic JDBC:
2. Next, Alt-Tab back to WebLogics window and wait to see the results. You
should see the debug statements printed as WebLogic checks the connection
pool connection to the database. If this was an application generating queries
or something wrong with the database, this might give you a better idea of
what is happening.
3. The good thing here is that this can be carefully turned on and off in production
using scripts. This can help administrators gather data without restarting
servers. To turn it off, run the corresponding debug off script:
- 41 -
TIP: Look at the DEBUG_ON and OFF scripts for ways to potentially
parameterize them based on your specific needs. This may require help from
scripting knowledge, but is worth the effort.
- 42 -
Lab 5 Monitoring
Monitoring is a broad topic that cannot possibly be completely covered in a single
session. There are many ways that administrators use to collect data and watch the
WebLogic environment. Some of these include:
Tools such as Oracle Enterprise Manager, Tivoli, HP BAC
Scripts run at intervals
Command Line (netstat, ps, etc)
SNMP tools
Load-Generation tools that check actual results
WebLogic Console
Log file scrapers
Java programs that use JMX
Activity 1 WLST Script
1. The first activity here will be to run a WLST-based status script that checks the
heap size of the WebLogic server. This type of script could collect any of the
thousands of monitor-able attributes. In this case, the script checks and prints.
In a real script, you might take action at this point.
- 43 -
Activity 2 WebLogic Console

1. Another popular place to monitor WebLogic is the WLS console. Here you will
open a browser to WLS Console and look through the server monitoring area.
To do this, use the tree on the left to see Environment Servers
AdminServer. There are entire areas of the console dedicated to monitoring.
Click through the tabs here to see some of what is available:
- 44 -
2. Under the Performance tab, you will see that thread dumps can be taken, as
well as a refresh button that will reload this information every 10 seconds:
- 45 -
TIP: The refresh button

periodically.
will cause the console to refresh this information
3. Log files can also be viewed directly from the console. That can help in not
required shell access to a log message. Filters and limits are built into this
section. To see it, use Diagnostics Log Files and select the log that you
need:
4. This area on the left (now under Diagnostic Images) can also help identify
where diagnostic images are stored. Here you should have one that was
generated in the previous lab, so here we will open it and look inside of it.
Support personnel may be able to understand more than you, but at the very
least you will be able to attain some basic information about when the
- 46 -
snapshot was taken. In this case, open it via WinZip and look at the JVM.img
file using the internal viewer. This is an XML file, so it is easily readable:
Activity 3 WLS Console Extension

1. The final piece of monitoring well do is to install and look at the WebLogic
Diagnostics Framework Console Extension. This surfaces JMX-based
diagnostic information through the WebLogic console, so that it is easily
consumable. To install it, simply stop the running server and perform the
following file copy operation:
Copy from <WL_HOME>\server\lib\console-ext :
- 47 -
to <DOMAIN_HOME>\console-ext:
- 48 -
2. Restart the server and navigate the browser to the WebLogic Server Console.
Observe the new top-level tab and click on it.
3. Select JVM Runtime View and watch for a few seconds. You should observe
free and total memory being graphed over time. This graph can support any
number of runtime attributes, and is fully extensible. If time permits, explore
the Console extension, add and remove a couple graphable components, and
see how the hierarchy relates to what you saw in Lab 3.
- 49 -
Activity 4 JMX Code (optional)

This example shows how to use code to access Java Management Extensions (JMX)
that are exposed by WebLogic Server. You may have developers who write this type
of code to perform specific tasks or custom monitoring against WebLogic servers or
clusters. During this activity, you will use the Eclipse IDE to import a code project and
run a JAVA application to connect to WebLogic and obtain information.
1. First, open the Eclipse IDE (Branded as Oracle Enterprise Pack for Eclipse).
Create a new workspace and go to the Workbench area.
- 50 -
2. Ensure that your WebLogic Server is still running from the previous activity, or
start it if you need to.
3. Import the pre-built project by right-clicking in the Project Explorer and
selecting Import
- 51 -
- 52 -
4. Open the source file called PrintServerState.java.
5. Attempt to run this by using the Run button and selecting Java Application.
This will fail initially because we havent assigned the connection parameters to
this code yet.
- 53 -
This fails (below) because we havent set input parameters yet.
6. To assign parameters, open the Run Configurations box, and enter the
following information into the Arguments panel:
- 54 -
7. Run the program again and observe the results. You will see that the code
connected to WebLogic and brought back a piece of information.
- 55 -
8. (Optional) There is another program here called MonitorServlets.java.

Configure and run this to see different information.
TIP: Use the Run Configurations to copy/paste parameters to programs that
have similar inputs
- 56 -
Lab 6 JDeveloper and ADF

This lab will show you how to install and configure JDeveloper to work with your
WebLogic domain. Although JDev comes with a built-in WebLogic domain, it is
sometimes helpful to learn to set it up against a free-standing domain which does not
run within the IDE.
Activity 1 Install JDeveloper + ADF
1. As mentioned in Lab 1, you can install either of the standalone WebLogic
installers, or you can install the JDeveloper + WebLogic installer. One good
thing here is that if you already have the standalone installation, you can
simply add to it by running the other installer. Here you see the installer telling
us we have a standalone WebLogic and offering to add JDeveloper and ADF
to it.
- 57 -
2. Complete the installation by selecting the defaults at each screen. When

complete, you can verify the additional products within the installation directory.
- 58 -
Activity 2 ADF Domain

1. Open the same Domain Configuration wizard we used back in Lab 1. At the
screen which offers the domain types, note that Oracle JRF (ADF) is now an
option. Select it for the new domain well create.
- 59 -
2. Complete the wizard using defaults, calling this domain adf_domain. The
password should be set to weblogic1, as it was in the previous domains.
Notice that additional applications and components are already deployed,
which is made possible using the WebLogic domain templating you have
learned.
- 60 -
3. (Optional) Before starting the domain, create a ZIP file of it, so that you can
start over without running the wizard again.
4. Start the domain from the command line, as you have done before. It may
take longer to start than our vanilla domain did, but that is due to it having more
components.
5. Open the console in the browser and verify that the domain is running. Under
Deployments, you will see the components called Oracle Java Required Files
(JRF), which allow ADF to function.
- 61 -
Activity 3 Link JDev to ADF Domain

1. Open JDeveloper 11g from the Start Menu. Select the Default Role and no to
the migration question.
- 62 -
2. After accepting the defaults, changing file associations, and answering other
dialogs that may come up, you see that JDev goes and creates its Integrated
Domain, which you can use with ADF applications. Activity 2 created a
standalone domain, which is more typical of what you will find in anything but a
developer workstation.
3. Create a new Fusion Web application called ADFApp. This is not meant to
be an ADF tutorial, but rather to show the ease of connectivity. After naming
the application, click Finish to complete the process.
- 63 -
4. Make a new JSF Page as shown, and add some content to the center pane so
it will show something in a browser.
- 64 -
- 65 -
5. Click run (F11) and watch as JDev compiles the application and starts the
default server of WebLogic. After this is complete, the page we created should
appear in the browser.
- 66 -
6. In order to switch this to our domain, close out of the browser and stop the
running Default Server from JDev. After we switch it use ours, this will not
occur again.
7. To switch domains, use the application dialog, which is the icon above the
context menu in this screen shot. Select Application Properties and look for
the Run section. You should see the Default Server listed as the Bind
Application to parameter. Click Edit Server Instances
- 67 -
- 68 -
- 69 -
8. From this dialog, you will define a new connection to our domain, and in the
previous dialog, you will then select it as the default for running ADF
applications against. After clicking New, you will click the green + sign and
create an actual WebLogic Server connection. Proceed to the testing screen
using the correct domain name (adf_domain), username (weblogic), and
password (weblogic1).
- 70 -
- 71 -
- 72 -
- 73 -
9. Test the connection as shown and ensure that all of the tests are successful.
- 74 -
10. Finish and name the new Server Connection
- 75 -
11. Finally, select the new domain connection as the default for the application,
back in the Application Properties window.
- 76 -
12. Now, when running the application from within JDeveloper, you should see it
use our domain for the application. You can tell it is because our domain is
port 7001 and the Integrated one was 7101.
- 77 -
Appendix A Command-Line Installation

Lab 1 showed you a simple product installation using the default options. If you are
operating on a system without GUI access, such as a remote Linux or Solaris box, it
is helpful to see the command line installer being run. It will essentially do the same
thing as the GUI version from Lab 1, but is console-driven.
Invoke the installer by opening a command prompt from the Windows start menu.
Navigate to the <INSTALL> directory and execute the command as shown:
oepe11_wls1031.exe -mode=console
- 78 -
Appendix B Console Mode Domain

From a command prompt (any directory), run the following command. Hit <enter> on
the first screen to create a new domain.
c:\weblogic\wlserver_10.3\common\bin\config.cmd -mode=console
- 79 -

WLS Admin 11gR1 Lab Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

WLS Admin 11gR1 Lab Guide

Hochgeladen von

Copyright:

Verfügbare Formate

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Lab 1 Product Installation

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Lab 2 Create a WebLogic Domain

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Activity 2 Domain From Scratch

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

8. Delete the entire <DOMAIN_HOME> directory from Windows Explorer.

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop

Activity 2 Script Recording

Copyright 2009, Oracle. All rights reserved.

WebLogic Server 11g Workshop