Oracle WebLogic Server 12c Advanced Administration Cookbook

By Dalton Iwazaki
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Install, Configure, and Run

About this book

Oracle WebLogic Server is the core application server product of the Oracle Fusion Middleware platform.


It is the premier application server for enterprise applications and has now been updated to 12C.


If your company or client uses Oracle technology then you must know how to administer the Oracle WebLogic Server

Oracle WebLogic Server 12c Advanced Administration Cookbook guides you through 70 recipes covering from the basics of WebLogic 12c installation, and passing through JDBC, JMS, cluster configuration and tuning. The book covers the day-by-day tasks of a WebLogic Administrator, enhanced with a lot of tips to build a WebLogic production environment focused on stability, high availability and performance.

The best place to start with any book is at the beginning so the first thing that is covered is the basics. This quick refresher should get you back up to speed with WebLogic server and get you in the right frame of mind to get stuck into the more complex techniques.


Each chapter then covers a specific topic with complex solutions simplified and explained. This is not only a book that guides you through complex techniques but also ensure you have a solid understanding of the theory behind the techniques.


We dive into high availability clusters, configuring JMS and JDBC, and then moving on to more general WebLogic Server aspects. Monitor, troubleshoot, and tune the performance of your WebLogic server with time tested solutions.


If you want to take your WebLogic server to the next level of performance and security or simply just want to be more in control this book is full of solutions that will allow you to achieve that aim.

Publication date:
June 2013
Publisher
Packt
Pages
284
ISBN
9781849686846

 

Chapter 1. Install, Configure, and Run

In this chapter, we will cover the following recipes:

  • Installing WebLogic Server 12c

  • Creating the WebLogic domain

  • Distributing the domain files to remote machines

  • Starting the Node Manager

  • Starting the Administration Server

  • Saving and activating changes in the Administration Console

  • Protecting changes in the Administration Console

  • Extending and customizing the Administration Console

  • Enabling RESTful Management Services

  • Starting/Stopping the WebLogic Managed Server

  • Deploying applications

 

Introduction


WebLogic Server is Oracle's flagship J2EE application server and is the foundation of the Oracle Fusion Middleware range of products, such as Oracle SOA Suite, Oracle WebCenter, and Oracle Service Bus. The new 12c version is being fully integrated with Oracle's Middleware products, and the system administrators who are already familiar with the core WebLogic administration tasks will be one step ahead of the market demand.

Oracle WebLogic Server 12c applications and systems deployed in production environments normally require performance, scalability, and high availability; these are usually not needed in a development environment. The recipes in this book focus on achieving these objectives.

This chapter condenses the core tasks a WebLogic administrator should know, such as downloading the correct package, installing it, and creating a WebLogic domain, configuring it, and managing it.

 

Installing WebLogic Server 12c


You should already be familiar with basic WebLogic installation, so this recipe covers the steps to a quick installation of WebLogic Server 12c in production environments.

This recipe will focus on a new install rather than upgrades or migrations.

Getting ready

It is important to navigate through Oracle's website and check if the chosen hardware and operational system architectures are supported in Certification Matrix before installing WebLogic Server. You should look for system requirements and supported platforms for WebLogic Server 12c. This is crucial for a production environment since Oracle Support verifies if you are running a supported configuration when an issue appears.

The book assumes the following hardware and software architectures for WebLogic Server 12c installations:

  • X86-64 processor (such as Intel Xeon or AMD Opteron)

  • Linux x86-64 architecture (such as Red Hat Enterprise Linux or Oracle Linux)

Operational systems based on Linux x86-64 (64-bit) are the most commonly used in production environments, and these instructions should cover other Unix architectures as well.

Note

The use of WebLogic Server in Microsoft Windows for production environments will not be considered in this book.

Oracle JRockit 6 for Linux x86-64 is the Java Virtual Machine (JVM) that has been used through the rest of this book. Download it at http://www.oracle.com/technetwork/middleware/jrockit/downloads. The filename is jrockit-jdk1.6.0_XXX-linux-x64.bin, where XXX stands for the JRockit release and JDK version.

The package WebLogic Server 12 c (12.1.1) generic installer (997 MB) for use with 64-bit JVMs should also be downloaded at http://www.oracle.com/technetwork/middleware/weblogic/downloads. The filename is wls1211_generic.jar.

Note

To simplify the reading, we'll use the following terms when referring to the directories:

  • $JAVA_HOME to JRockit/Java Home directory: /oracle/jvm

  • $MW_HOME to Middleware Home: /oracle/Middleware

  • $WL_HOME to WebLogic Home: /oracle/Middleware/wlserver_12.1

How to do it...

Carry out the following steps to install WebLogic Server 12c:

  1. Create a dedicated user to host and run WebLogic Server 12c in Linux. Log in as the root user and create the user and the group named wls, and define a new password for it:

    [[email protected]]# groupadd wls
    [[email protected]]# useradd -g wls wls
    [[email protected]]# passwd wls
    Changing password for user wls.
    New UNIX password: <new password>
    Retype new UNIX password: <new password>
    
  2. Log in as the wls user and set the correct file permissions:

    [[email protected]]$ umask 027
    
  3. Run the JRockit installer in console mode and install JRockit:

    [[email protected]]$ ./jrockit-jdk1.6_xxx-linux-x64.bin -mode=console
    
  4. Follow the onscreen instructions and type/oracle/jvm in the Product Installation directory. You can just press Enter for all the other options. JRockit will be installed without the demos and with no source code.

  5. Run WebLogic Server 12c Generic Installer in console mode:

    [[email protected]]$ /oracle/jvm/bin/java –jar wls1211_generic.jar –mode=console
    
  6. Follow the onscreen instructions and type/oracle/Middleware for the "Middleware Home" = [Enter new value or use default] screen. Press Enter to move forward.

  7. Skip the Register for Security Updates screen by typing 3 to navigate to 3|Receive Security Update:[Yes], then type No and then Yes. Press Enter to move forward.

  8. Type 1 to select the 1|Typical option on the Install Type screen.

  9. The freshly installed /oracle/jvm JDK should be selected. If not, add it by typing 1 for 1|Add Local Jdk.

  10. Press Enter to confirm all the other screens.

How it works...

These install instructions will provide a clean and fresh WebLogic Server 12c installation in the prod01 hostname.

It also covers some basic user administration in Linux that can be skipped if you already have an operational system user.

Tip

Don't forget to set the correct file permissions with umask before installing WebLogic Server 12c.

Both JRockit and WebLogic Server were installed in the console mode option without any graphical interface. Production environments are more restricted, and console mode requires only a terminal; it is faster and does not need an X11 Server.

Generic installer is used to install WebLogic since it is the one that contains the native library for x86-64. The native library is important because it enables the use of a native socket reader that is much faster than the pure Java socket reader. This library enables what is called the performance pack on WebLogic and is mandatory in a production environment.

The installation process is very straightforward and only copies the files to their directories. The next step is to create a new WebLogic domain.

See also

  • Creating the WebLogic domain

 

Creating the WebLogic domain


With WebLogic Server 12c installed, you can now create a new WebLogic domain.

The WebLogic domain is the central configuration entity of WebLogic Server. The domain should have at least one WebLogic Server instance with the role of the Administration Server. The Administration Server is the access point used for configuration, deployment, and monitoring.

More WebLogic Server instances can be created to be part of the domain. All other WebLogic Server instances of the domain that are not the Administration Server are called the Managed Servers. They should host the deployed applications and resources.

A WebLogic cluster can also be added to the domain. The cluster consists of one or more Managed Servers acting as one single entity. A single WebLogic Server installation is not restricted to one WebLogic domain, and more domains can be created using the same installation.

Getting ready

Before creating a new WebLogic domain, you have to plan and define its architecture. For production environments, it is mandatory to use WebLogic clusters with a minimum architecture of at least two WebLogic Server instances (the Managed Servers) in two different machines. The objective is to avoid having a single point of failure.

We will create a new WebLogic domain called PROD_DOMAIN with an administration instance (AdminServer) named PROD_AdminServer and a WebLogic cluster PROD_Cluster with the two Managed Servers PROD_Server01 and PROD_Server02. The two machines hosts are called prod01 and prod02. Since you have already installed WebLogic Server 12c in prod01, install it in prod02 as well. We will assume these names throughout the entire book.

The machines prod01 and prod02 should also have IP addresses assigned and be visible through the network. It's recommended to use the fully qualified domain name (FQDN) of the servers. In this recipe, and the rest of the book, prod01 is prod01.domain.local and the hostname of the prod02 machine is prod02.domain.local.

Note

To simplify the reading, we'll use the following term when referring to the directories:

$DOMAIN_HOME to the created WebLogic Domain directory—/oracle/Middleware/user_projects/domains/PROD_DOMAIN.

How to do it...

To create a new WebLogic domain, follow the ensuing steps:

  1. Log in as a wls user on the first machine prod01 and navigate to the following folder:

    [[email protected]]$ cd $WL_HOME/common/bin

  2. Start WebLogic Configuration Wizard in console mode:

    [[email protected]]$ ./config.sh -mode=console
    
  3. Follow the onscreen instructions and type 1, and press Enter to select the Create a new WebLogic domain option on the Welcome screen.

  4. Type 1 and press Enter to select the Choose WebLogic Platform components option on the Select Domain Source screen.

  5. Press Enter again to continue with the Basic WebLogic Server Domain - 12.1.1.0 [wlserver_12.1] template.

  6. On the Edit Domain Information screen, type the domain name PROD_DOMAIN and press Enter twice.

  7. Leave /oracle/Middleware/user_projects/domains unchanged on the Select the target domain directory for this domain screen and press Enter.

  8. On the Configure Administrator User Name and Password screen, set the WebLogic administrator username and password. Type the username as wlsadmin and type 2 to set the password and 3 to type the password again and confirm it. Press Enter to move forward.

  9. The Domain Mode Configuration screen is where you set the production mode. Type 2 and press Enter.

  10. The installed JRockit should already be selected as /oracle/jvm on the Java SDK Selection screen. Press Enter to continue.

  11. On the Select Optional Configuration screen, type 1 for the Administration Server and 2 for the Managed Servers, clusters, and machines.

  12. On the Configure the Administration Server screen, type 1 to set the Administration Server name as PROD_AdminServer. Leave the other options in their default values and press Enter to move to the next screen.

  13. Then add the two Managed Server instances on the Configure Managed Servers screen.

  14. Type PROD_Server01 to add the first server, then type 2 to modify the listen address to prod01.domain.local. Type 3 to modify the port to 8001, press Enter, and then type 5 to finish this server.

  15. Do the same for the second server and type 1 to add, type PROD_Server02 as the name, and type 2 to modify the listen address to prod02.domain.local. Type 3 to modify the port to 8002. Press Enter to continue.

  16. Add the cluster on the Configure Clusters screen. Type PROD_Cluster and press Enter to create it. Type 3 and modify the Cluster Address field to prod01.domain.local:8001,prod02.domain.local:8002.

  17. The next screen is the Assign Servers to Clusters screen. Type 1 to select PROD_Cluster. Then type 2 to Select All and press Enter. Confirm it by pressing Enter again.

  18. Configure the two machines on the Configure Machine screen. Type prod01 and press Enter. Type 2 to change the listen address to prod01.domain.local as well. Type 4 when done.

  19. Add the second machine typing 1 and name it as prod02. Press Enter and press Enter again to skip the Unix Machine screen.

  20. You will now assign the Managed Servers to their respective machines on the Assign Servers to Machines screen.

  21. Type 1.1 to choose prod01 and type 1 and press Enter. Now type 1-2 and press Enter assigning the PROD_AdminServer and PROD_Server01 servers. Press Enter again to return.

  22. Type 1.2 to choose prod02, then type 1 and 1 again, and press Enter to finish.

How it works...

A new domain was created in the console mode using the Configuration Wizard. Console mode was used instead of graphical interface mode due to the usual restrictions of a production environment.

The PROD_DOMAIN domain was created with one the Administration Server named PROD_AdminServer and one cluster PROD_Cluster containing the two Managed Servers PROD_Server01 and PROD_Server02.

The WebLogic domains can work in two different modes: production and development. The development mode is only recommended to be used in single WebLogic instance domains, normally at the developer desktop. The PROD_DOMAIN domain was created in Production mode, which deactivates some features such as auto-deployment.

Tip

It's good practice to use a prefix such as PROD when naming the domain, the cluster, and the servers. It can be hard to find WebLogic Server when working with a production farm that contains hundreds of WebLogic instances.

The domain contains what is considered to be a minimum architecture for a production environment. With the two Managed Servers of the cluster hosted by different machines, the platform avoids a single point of failure in the case of a machine crash.

There's more...

You can create the domain using the Configuration Wizard in graphical mode with all the same options if you have a functional X11 Server.

See also

  • Distributing the domain files to remote machines

 

Distributing the domain files to remote machines


A new domain is installed and configured in one machine (prod01). Since the architecture includes another machine (prod02), the domain files now have to be distributed in all the machines of the domain.

This recipe contains the steps to distribute the files either by using the built-in WebLogic tools pack and unpack or by copying them manually in the command line of the shell.

Getting ready

Create a new template of the domain using the pack command in the prod01 machine. With the template created in prod01, use the unpack command to distribute the files to the machine prod02 (and to all machines used by the WebLogic cluster).

How to do it...

Carry out the following steps to distribute the domain files:

  1. Log in as a wls user on the first machine prod01 and navigate to the folder:

    [[email protected]]$ cd $WL_HOME/common/bin
    
  2. Run the following command:

    [[email protected]]$ ./pack.sh -domain=$DOMAIN_HOME-template=$WL_HOME/common/templates/domains/PROD_DOMAIN_template.jar -template_name=PROD_DOMAIN –managed=true
    

    A file $WL_HOME/common/templates/domains/PROD_DOMAIN_template.jar will be created.

  3. Log in as a wls user on the second machine prod02 and copy the template from prod01 to prod02:

    [[email protected]]$ scp [email protected]:$WL_HOME/common/templates/domains/PROD_DOMAIN_template.jar $WL_HOME/common/templates/domains/
    
  4. Run the following commands to unpack the template:

    [[email protected]]$ cd $WL_HOME/common/bin
    [[email protected]]$ ./unpack.sh -template=$WL_HOME/common/templates/domains/PROD_DOMAIN_template.jar –domain=$DOMAIN_HOME
    

How it works...

The unpack command will create the necessary files to host the WebLogic domain PROD_DOMAIN on the prod02 machine based on the template created with the pack command on prod01.

An entry to the PROD_DOMAIN domain will automatically be added to the nodemanager.properties file.

There's more...

We can also distribute the WebLogic domain files manually. In this section, we will see how this can be achieved.

Distributing WebLogic domain files manually

You can simply copy the domain files manually too; just don't forget to edit the nodemanager.domains file and add the domain entry.

As in the prior chapter and the rest of the book, the $DOMAIN_HOME environment variable points to the/oracle/Middleware/user_projects/domains/PROD_DOMAIN directory.

  1. Log in as a wls user on the machine prod02 and copy the domain from prod01:

    [[email protected]]$ mkdir –p $DOMAIN_HOME
    [[email protected]]$ scp –rp [email protected]:$DOMAIN_HOME $DOMAIN_HOME/..
    
  2. Edit the nodemanager.domains file:

    [[email protected]]$ vi $WL_HOME/common/nodemanager/nodemanager.domains
    
  3. Add the following entry if it doesn't exist:

    PROD_DOMAIN=/oracle/Middleware/user_projects/domains/PROD_DOMAIN/
    

See also

  • Starting the Node Manager

 

Starting the Node Manager


The Node Manager is the WebLogic Server utility to control the lifecycle—start, stop, restart—of the WebLogic Managed Server instances and the Administration Server.

In production environments, the Node Manager is needed to meet the high availability requirements.

In this recipe, the system administrator will learn how to start and stop the Node Manager.

Getting ready

The Node Manager is already installed with WebLogic Server 12c. There are two versions of the Node Manager: a Java version and a script version. This recipe will cover the Java version. The Java version is the most commonly used version, and it is more complete and more secure than the script version.

How to do it...

  1. Log in as a wls user on the first machine prod01 and navigate to the folder:

    [[email protected]]$ cd $WL_HOME/server/bin
    
  2. Start the Node Manager in the background. Since it's the first time you are starting it, the $WL_HOME/common/nodemanager/nodemanager.properties file will be created.

    [[email protected]]$ nohup ./startNodeManager.sh &
    [1] <PID>
    nohup: appending output to `nohup.out'
    
  3. Do the same on the prod02 machine and on all the machines of the WebLogic domain.

How it works...

You can leave the default values created for nodemanager.properties.

The Node Manager has started and is listening to port 5556. The <PID> value is the number of the newly created process.

Since the prod01 and prod02 machines were configured when you created the WebLogic domain PROD_DOMAIN, the Node Manager should be reachable and able to receive start and stop commands from the Administration Console.

There's more...

In this section, we will see how to shut down the Node Manager:

Shutting down the Node Manager

There is no formal command to shut down the Node Manager, so you'll have to do it manually, killing the process:

  1. Find the <PID>value of the Node Manager process:

    [[email protected]]$ ps aux | grep weblogic.NodeManager | grep -v grep | awk '{print $2} '
    <PID>
    
  2. Issue a kill command to PID to finish it:

    [[email protected]]$ kill <PID>
    

    Or, force the process to finish:

    [[email protected]]$ kill -9 <PID>
    

See also

  • Starting the Administration Server

  • Starting/Stopping the WebLogic Managed Server

 

Starting the Administration Server


Administration Server is a WebLogic Server instance specific to administering a WebLogic domain through the Administration Console application at the /console URI.

It's a common task to deploy runtime applications to the Administration Server in development environments, but you should avoid doing it in production. Leave the Administration Server only to the administrative tasks of the console.

Getting ready

Since there is only one Administration Server per WebLogic domain, you have to start the Administration Server only in prod01.

How to do it...

To start the Administration Server, follow the ensuing steps:

  1. Log in as the wls user on the first machine prod01 and navigate to the folder:

    [[email protected]]$ cd $DOMAIN_HOME/bin
    
  2. Start the Administration Server:

    [[email protected]]$ ./startWebLogic.sh
    
  3. The server will initiate the startup process and ask for the WebLogic Administrator username and password:

    Enter username to boot WebLogic server: wlsadmin
    Enter password to boot WebLogic server:
    
  4. Type wlsadmin as the username and the <password> value you previously specified during domain creation.

  5. WebLogic Administration Server will start.

How it works...

The Administration Server is now running and waiting for connections in the host and port that are specified during domain creation at http://prod01.domain.local:7001/console.

<Started the WebLogic Server Administration Server "PROD_AdminServer" for domain "PROD_DOMAIN" running in production mode.>

There's more...

The system administrator should also create a boot.properties file to avoid entering the boot username and password in every WebLogic Server startup.

Creating the boot.properties file

Specify a boot.properties file so the Administration Server doesn't ask for the username and password at startup.

  1. Go to the Administration Server root folder:

    [[email protected]]$ cd $DOMAIN_HOME/servers/PROD_AdminServer
    
  2. Create and enter a new directory:

    [[email protected]]$ mkdir security
    [[email protected]]$ cd security
    
  3. Create a new file called boot.properties with wlsadmin as the username and the <password> value you specified:

    [[email protected]]$ echo -ne "username=wlsadmin\npassword=<password>" > boot.properties
    
    [[email protected]]$ cat boot.properties
    username=wlsadmin
    password=<password>
    
  4. The next time you start WebLogic Administration Server, it will use the credentials from the boot.properties file. The file will also be encrypted:

    [[email protected]]$ cat boot.properties
    password={AES}If68A2GSiO6Fa8w4j0giDJGR0FATHnfPsoZvpmF/Ipc\=
    username={AES}UYyIQYkN6z5o8PsS/IccG3VgZv6LP1zj+Ro1JBDb2ZE\=
    

Starting the Administration Server in the background

You usually start the Administration Server as a background process in Linux.

  1. Go to the WebLogic domain's bin directory:

    [[email protected]]$ cd $DOMAIN_HOME/bin
    
  2. Start the Administration Server in the background:

    [[email protected]]$ nohup ./startWebLogic.sh &
    [1] <PID>
    

The <PID> value is the process ID of the Administration Server.

The standard output (stdout) and standard error (stderr) of the process will be appended to a file called $DOMAIN_HOME/bin/nohup.out.

Accessing the Administration Console

The Administration Console application is running in the Administration Server. To access it, follow the ensuing steps:

  1. Open your web browser and navigate to http://prod01.domain.local:7001/console:

  2. Type the wlsadmin username and the password that was specified earlier.

See also

  • Starting the Node Manager

  • Starting/Stopping the WebLogic Managed Server

 

Saving and activating changes in the Administration Console


The Administration Console is the central application for administering your WebLogic domain. The WebLogic domain PROD_DOMAIN was configured to start in production mode; this means you'll have to obtain the domain configuration lock before saving and activating changes. This protection is to prevent changes from other users during your edit session.

Getting ready

WebLogic Administration Server must be up and running.

How to do it...

Carry out the following steps to save and activate changes:

  1. Access the Administration Console with your web browser at http://prod01.domain.local:7001/console.

  2. Obtain the configuration lock by clicking on Lock & Edit:

  3. Make the necessary changes and click on the Save button to save it.

  4. If there are any configuration changes pending, the Lock & Edit button should be labeled now as Activate Changes:

  5. Click on the Activate Changes button to confirm the changes.

How it works...

All saved changes made before activating the session are saved in the $DOMAIN_HOME/pending directory. It contains the new version of the configuration files (config.xml). As soon as the Activate Changes option is clicked on, the Administration Server issues a command to all the WebLogic Managed Server instances to update the configuration. If any of the Managed Servers do not accept the new configuration, the changes are rolled back and the Administration Console will show a message. If the new configuration is accepted by the Managed Servers, the changes will be activated and the configuration files will be updated by all the servers and one very machine belonging to the domain.

There's more...

The system administrator can also make configuration changes through WLST.

Making changes using the WLST

Under the hood, WebLogic Server uses a JMX framework that exposes WebLogic MBeans to manage its configuration. The Administration Console issues JMX commands as you make changes to Configuration Manager MBean. MBeans can be accessed through WLST.

Edit, save, and activate the changes through WLST:

  1. Log in as a wls user to shell and start WLST:

    [[email protected]]$ $WL_HOME/common/bin/wlst.sh
    Welcome to WebLogic Server Administration Scripting Shell
    Type help() for help on available commands
    wls:/offline>
    
  2. Connect to the Administration Server using wlsadmin as the user, <pwd> as the password, and t3://prod01.domain.local:7001 as the server URL:

    wls:/offline>connect("wlsadmin","<pwd>","t3://prod01.domain.local:7001")
    Connecting to t3://prod01.domain.local:7001 with userid wlsadmin ...
    Successfully connected to Admin Server 'PROD_AdminServer' that belongs to domain 'PROD_DOMAIN'.
    wls:/PROD_DOMAIN/serverConfig>
    
  3. Start the editing, make the necessary changes, and activate it in the end:

    wls:/PROD_DOMAIN/serverConfig>edit()
    Location changed to edit tree. This is a writable tree with
    DomainMBean as the root. To make changes you will need to start
    an edit session via startEdit().
    
    For more help, use help(edit)
    You already have an edit session in progress and hence WLST will
    continue with your edit session.
    
    wls:/PROD_DOMAIN/edit !>startEdit()
    Starting an edit session ...
    Started edit session, please be sure to save and activate your
    changes once you are done.
    
    wls:/PROD_DOMAIN/edit !>< make necessary changes >
    
    wls:/PROD_DOMAIN/edit !> save()
    Saving all your changes ...
    Saved all your changes successfully.
    
    wls:/PROD_DOMAIN/edit !>activate()
    Activating all your changes, this may take a while ...
    The edit lock associated with this edit session is released
    once the activation is completed.
    
    Activation completed
    
    wls:/PROD_DOMAIN/edit> exit()
    Exiting WebLogic Scripting Tool
    

See also

  • Starting the Administration Server

 

Protecting changes in the Administration Console


Change management in a production environment is critical and has to be done with careful preparation and planning. WebLogic provides a way to save and later track all the changes made in its configuration.

This recipe focuses on how to enable the embedded configuration backup, how to enable the configuration changes audit, and how to automatically record a Jython script to all the changes made in the Administration Console that can be used later with WLST.

Getting ready

WebLogic Administration Server must be up and running.

How to do it...

Carry out the following steps to protect the configuration changes:

  1. Access the Administration Console with your web browser at http://prod01.domain.local:7001/console.

  2. Click on the Preferences link.

  3. Enable the following checkboxes:

    Show Advanced Sections

    Warn If User Holds Lock

    Warn User Before Taking Lock

  4. Click on the Save button.

  5. Open the WLST Script Recording tab.

  6. Enable the following checkboxes:

    Append to File

    Automatic Recording

  7. Click on the Save button.

  8. Obtain the configuration lock by clicking on Lock & Edit.

  9. Click the PROD_DOMAIN link on the Domain Structure on the left.

  10. Choose Change Log and Audit in the Configuration Audit Type drop-down menu.

  11. Enable the Configuration Archive Enabled checkbox.

  12. Set the number of back files in the Archive Configuration Count text field. Type 250 as the value. The default value is 50.

  13. Click on the Save button.

  14. Activate the changes by clicking on the Activate Changes button.

  15. You will have to restart the Administration Server for the changes to take effect.

How it works...

The Preferences section changes will enable some messages in the Administration Console that will warn the user when the edit lock is already being used in another browser session. This is important in a production environment to avoid the changes being made by other administrators at the same time.

The WLST Script Recording changes will enable a Jython script to be recorded to every change made in the Administration Console. The script is recorded by default in the $DOMAIN_HOME root directory with a filename Script*.py.

With the backup configuration enabled, every time the domain configuration is modified, a JAR file containing the old configuration($DOMAIN_HOME/config/*) will be archived until the limit of 250 archives as you defined in Archive Configuration Count. Change the value so it suits your needs. JAR will be saved in the directory $DOMAIN_HOME/configArchive/config-XXX.jar. The lesser the XXX number, the older the configuration archive is.

The audit configuration registers every step and change made in the Administration Server log file (.log). The following example shows the wlsadmin user changing the JTA timeout from 30 to 300:

<BEA-159904><USER wlsadmin MODIFIED com.bea:Name=PROD_DOMAIN,Type=JTA ATTRIBUTE TimeoutSeconds FROM 30 TO 300>

There's more...

Enabling the protection changes can also be done through WLST.

Protecting changes using WLST

You can use WLST to make the exact same configuration changes. The exception is the Preferences section, which is a bunch of parameters from the Administration Console application and not from the WebLogic domain:

  1. Log in as a wls user to shell and start WLST:

    [[email protected]]$ $WL_HOME/common/bin/wlst.sh
    
  2. Connect to the Administration Server using wlsadmin as the user, <pwd> as the password, and t3://prod01.domain.local:7001 as the server URL:

    wls:/offline>connect("wlsadmin","<pwd>","t3://prod01.domain.local:7001")
    
  3. Run the following WLST commands:

    edit()
    startEdit()
    cmo.setConfigurationAuditType('logaudit')
    cmo.setConfigBackupEnabled(true)
    cmo.setArchiveConfigurationCount(250)
    save()
    activate()
    exit()
    

See also

  • Starting the Administration Server

  • Saving and activating changes in the Administration Console

 

Extending and customizing the Administration Console


The Administration Console is a Java web application based on the WebLogic portal that can be modified and extended. These console extensions can be used to customize the Administration Console layout, style, logos, and images, and also to add extra pages, and extra functionalities to monitor and manage WebLogic Server and deployed applications.

This recipe will focus on creating a simple console extension to change a few text elements of the PROD_DOMAIN the Administration Console.

Getting ready

This task requires you to have ANT installed. It can be downloaded at http://ant.apache.org. Download the latest stable build and install it. The filename should be apache-ant-XXX-bin.zip where XXX stands for the ANT version.

Note

All necessary work will be done in a Linux environment. You can assume the use of the prod01 machine in this recipe.

How to do it...

Carry out the following steps to customize and extend the Administration Console:

  1. Log in as a wls user to the first machine prod01 and unzip ANT:

    [[email protected]]$ cd /oracle
    [[email protected]]$ unzip apache-ant-XXX-bin.zip
    
  2. Create a symbolic link ant pointing to the apache-ant-XXX directory:

    [[email protected]]$ ln -s apache-ant-XXX ant
    [[email protected]]$ ls -l
    lrwxrwxrwx 1 wlswls   16 Aug  9 10:37 ant -> apache-ant-XXX
    drwxr-xr-x 6 wlswls 4096 May 22 06:24 apache-ant-XXX
    
  3. Export the environment variables:

    [[email protected]]$ export JAVA_HOME=/oracle/jvm
    [[email protected]]$ export ANT_HOME=/oracle/ant
    [[email protected]]$ export MW_HOME=/oracle/Middleware
    [[email protected]]$ export WL_HOME=/oracle/Middleware/wlserver_12.1
    [[email protected]]$ export PATH=$ANT_HOME/bin:$JAVA_HOME/bin:$PATH
    
  4. Change to the console extension templates directory:

    [[email protected]]$ cd $WL_HOME/server/lib/console-ext/templates
    
  5. Run ANT to expand the Look and Feel Template (laf):

    [[email protected]]$ ant -f build-new-laf.xml -Dname=myConsoleExt -Ddir=/oracle/myConsoleExt
    Buildfile: /oracle/Middleware/wlserver_12.1/server/lib/console-ext/templates/build-new-laf.xml
    
    all:
        [mkdir] Created dir: /oracle/myConsoleExt
        [unzip] Expanding: /oracle/Middleware/wlserver_12.1/server/lib/console-ext/templates/laftemplate.zip into /oracle/myConsoleExt
         [move] Moving 1 file to /oracle/myConsoleExt/framework/markup/lookandfeel
    
    BUILD SUCCESSFUL
    Total time: 1 second
    
  6. Extract and copy the default message bundle global.properties to the project from the console.jar file:

    [[email protected]]$ cd /oracle/myConsoleExt/WEB-INF
    [[email protected]]$ mkdir classes
    [[email protected]]$ cd classes
    [[email protected]]$ $JAVA_HOME/bin/jar -xf $WL_HOME/server/lib/consoleapp/webapp/WEB-INF/lib/console.jar global.properties
    
  7. Edit global.properties:

    [[email protected]]$ vi global.properties
    
  8. Change the window.title and login.title values from:

    window.title=Oracle WebLogic Server Administration Console
    login.title=Welcome
    

    To:

    window.title=My Company-Oracle WebLogic Server Administration Console
    login.title=Welcome to "My Company"
    
  9. Archive the myConsoleExt extension and move the package to the PROD_DOMAIN console extensions directory:

    [[email protected]]$ cd /oracle/myConsoleExt
    [[email protected]]$ $JAVA_HOME/bin/jar -cf myConsoleExt.war *
    [[email protected]]$ mv myConsoleExt.war $DOMAIN_HOME/console-ext/
    
  10. Restart the Administration Server.

  11. Access the Administration Console login page and check the text changes.

  12. Before the changes are made, it should look like the following screenshot:

And afterwards, you will notice the changes highlighted in the following image:

How it works...

You created a myConsoleExt.war console extension application that changes some of the text of the Administration Console.

Other modifications can be made to the following resources to suit your customization needs:

  • Images:/oracle/myConsoleExt/images/*/oracle/myConsoleExt/framework/skins/myConsoleExt/images/*

  • Stylesheet:/oracle/myConsoleExt/css/*/oracle/myConsoleExt/framework/skins/myConsoleExt/css/*

  • JSP:/oracle/myConsoleExt/framework/skeletons/myConsoleExt/*

  • Text:/oracle/myConsoleExt/WEB-INF/classes/global.properties

The global.properties file is the generic resource bundle that holds the text messages. Depending on the internationalization needs, you may create the appropriate files for each language. More details can be found at http://docs.oracle.com/cd/E24329_01/web.1211/e24966/bundles.htm#g1076214.

There's more...

To remove the Administration Console extension or to add more pages and content to it, follow the given instructions.

Removing the console extension from the Administration Console

  1. Remove the myConsoleExt.war file from the PROD_DOMAIN console extensions directory:

    [[email protected]]$ rm -rf $DOMAIN_HOME/console-ext/myConsoleExt.war
    
  2. Restart the Administration Console.

    Tip

    Clean your browser cache before accessing the Administration Console again.

Adding pages and content to the Administration Console

Adding other content to Console involves developing a WebLogic portal web application, using NetUI, portlets, JSP, and other J2EE technology. It is a Java programming task, which is beyond the scope of this book.

You can check Oracle's documentation at http://docs.oracle.com/cd/E24329_01/web.1211/e24966/addcontrols.htm#CNSLX159.

See also

  • Starting the Administration Server

  • Saving and activating changes in the Administration Console

 

Enabling RESTful Management Services


WebLogic Server 12c introduces the possibility of monitoring WebLogic Server using RESTful Web Services with new RESTful Management Services.

RESTful Management Services is disabled by default. This recipe will enable it.

Getting ready

WebLogic Administration Server must be up and running.

To enable WebLogic RESTful Management Services, you have to access the Administration Console at http://prod01.domain.local:7001/console.

How to do it...

Carry out the following steps to enable RESTful Management Services:

  1. Access the Administration Console with your web browser at http://prod01.domain.local:7001/console.

  2. Click on the Lock & Edit button to create a new change session.

  3. Navigate to Settings for Domain | General by clicking Home and then Domain or by clicking the PROD_DOMAIN link.

  4. Check the Enable RESTful Management Services checkbox, as shown in the following screenshot:

  5. Restart WebLogic Administration Server and all Servers of the domain.

How it works...

RESTful Management Services exposes WebLogic Server instances and WebLogic clusters, applications, and data sources to be monitored using the HTTP GET method and RESTful formats, such as XML, JSON, and HTML.

The following table displays the resources to be monitored and the corresponding URIs to be accessed.

Resource

URI

Servers

http://prod01.domain.local:7001/management/tenant-monitoring/servers

Specific Server

http://prod01.domain.local:7001/management/tenant-monitoring/servers/<servername>

Clusters

http://prod01.domain.local:7001/management/tenant-monitoring/clusters

Specific Cluster

http://prod01.domain.local:7001/management/tenant-monitoring/clusters/<clustername>

Applications

http://prod01.domain.local:7001/management/tenant-monitoring/applications

Specific Application

http://prod01.domain.local:7001/management/tenant-monitoring/ applications/<applicationame>

Data Sources

http://prod01.domain.local:7001/management/tenant-monitoring/datasources

Specific Data Source

http://prod01.domain.local:7001/management/tenant-monitoring/datasources/<datasourcename>

Note

To access the full response format of each resource, add "?format=full"at the end of the URI.

The following image illustrates a RESTful request to monitor all servers of the domain. It contains the name, state, and health of the Administration Server instance PROD_AdminServer. It also contains the WebLogic version, the machine that this server is running, open sockets, the Java version, the operational system, the Java heap size, and the Java heap in use. The PROD_Server01 and PROD_Server02 instances are down, and their state is also displayed as SHUTDOWN:

There's more...

RESTful Management Services can also be enabled through WLST.

Enabling RESTful using WLST

  1. Log in as a wls user to shell and start WLST:

    [[email protected]]$ $WL_HOME/common/bin/wlst.sh
    
  2. Connect to the Administration Server using wlsadmin as the user, <pwd> as the password, and t3://prod01.domain.local:7001 as the server URL:

    wls:/offline>connect("wlsadmin","<pwd>","t3://prod01.domain.local:7001")
    
  3. Run the following WLST commands:

    edit()
    startEdit()
    cd('/RestfulManagementServices/PROD_DOMAIN')
    cmo.setEnabled(true)
    save()
    activate()
    exit()
    
  4. Restart WebLogic Administration Server and all servers of the domain.

See also

  • Starting the Administration Server

  • Saving and activating changes in the Administration Console

 

Starting/Stopping the WebLogic Managed Server


This recipe will show how to start and stop the WebLogic Managed Server from the Administration Console.

Getting ready

The Node Manager must be up and running in each of the computers of the WebLogic domain.

How to do it...

Carry out the following steps to start and stop the WebLogic Managed Server:

  1. Access the Administration Console with your web browser at http://prod01.domain.local:7001/console.

  2. Navigate to the Settings for Domain page by clicking on Home and then Domain or by clicking the PROD_DOMAIN link.

  3. Click on the Control tab.

  4. Select the checkbox to the left of the WebLogic Server name, and click on the Start button to start the servers or the Shutdown button to shutdown. The Shutdown button has two options: When work completes or Force Shutdown Now. Select Force Shutdown Now.

  5. Confirm the operation by clicking on the Yes button on the Server Life Cycle Assistant page.

How it works...

When a start/stop operation is invoked for Managed Server, the Administration Console issues this command to the Node Manager. The Node Manager receives the startup parameters and credentials from the Administration Console and starts the Managed Server.

The Managed Server then contacts the Administration Server and checks for configuration changes and if necessary, updates it. If the Administration Server is not reachable, the Managed Server uses the local copy of the configuration from the $DOMAIN_HOME/config/* directory.

It's possible to start the WebLogic Server instances without the Node Manager; but unless you have your own monitoring and high availability method to the WebLogic domain, it is recommended to use the Node Manager in production environments.

There's more...

The Managed Server can also be started and stopped using WLST.

Starting/stopping the Managed Servers with WLST and the Node Manager

Carry out the following steps:

  1. Log in as a wls user to shell and start WLST:

    [[email protected]]$ $WL_HOME/common/bin/wlst.sh
    
  2. Connect to the Administration Server using wlsadmin as the user, <pwd> as the password, and t3://prod01.domain.local:7001 as the server URL:

    wls:/offline>connect("wlsadmin","<pwd>","t3://prod01.domain.local:7001")
    
  3. Run the following WLST command to start PROD_Server01:

    start('PROD_Server01','Server')
    
  4. To stop the Managed Server, type the following command:

    shutdown('PROD_Server01','Server')
    

The WLST method works the same way as the Administration Console. The Administration Console and WLST are both clients accessing the Node Manager, and both invoke start/stop operations on it.

Starting/stopping with the provided shell script

You can use the startManagedWebLogic.sh and stopManagedWebLogic.sh script located at the $DOMAIN_HOME/bin directory:

  1. Go to the WebLogic domain's bin directory:

    [[email protected]]$ cd $DOMAIN_HOME/bin
    
  2. Start the Managed Server PROD_Server01 typing:

    [[email protected]]$ ./startManagedWebLogic.sh PROD_Server01 t3://prod01.domain.local:7001
    
  3. The server will initiate the startup process and ask for a WebLogic administrator username and password:

    Enter username to boot WebLogic server: wlsadmin
    Enter password to boot WebLogic server:
    
  4. Type wlsadmin as the username and <password> you previously specified at the domain creation as the password.

  5. The WebLogic Managed Server will start.

  6. To stop the PROD_Server01 Managed Server, provide the credentials wlsadmin/<password>:

    [[email protected]]$ ./stopManagedWebLogic.sh PROD_Server01 t3://prod01.domain.local:7001
    Stopping Weblogic Server...
    
    Initializing WebLogic Scripting Tool (WLST) ...
    
    Welcome to WebLogic Server Administration Scripting Shell
    
    Type help() for help on available commands
    
    Please enter your username :wlsadmin
    Please enter your password :<password>
    Connecting to t3://prod01.domain.local:7001 with userid wlsadmin ...
    Successfully connected to Admin Server 'PROD_AdminServer' that belongs to domain 'PROD_DOMAIN'.
    
    Warning: An insecure protocol was used to connect to the
    server. To ensure on-the-wire security, the SSL port or
    Admin port should be used instead.
    
    Shutting down the server PROD_Server01 with force=false while connected to PROD_AdminServer ...
    
    Exiting WebLogic Scripting Tool.
    
    Done
    

Note

Scripts usage

startManagedWebLogic.sh <serverName> <admin_url>

stopManagedWebLogic.sh <serverName> <admin_url>

stopManagedWebLogic.sh <serverName> <admin_url> <user> <password>

The boot.properties file must be created the same way it was created before in order to provide the credentials, otherwise WebLogic will not start.

Tip

WebLogic Server will look for the credentials provided in the boot.properties file under $DOMAIN_HOME/servers/<servername>/security/ when starting from the script.

On the other hand, the credentials will be stored automatically in $DOMAIN_HOME/servers/<servername>/data/nodemanager/boot.properties if the startup command is issued to the Node Manager. WebLogic Server will not ask for the username/password.

See also

  • Starting the Node Manager

  • Starting the Administration Server

 

Deploying applications


This recipe will cover the deployment of a J2EE Application archived file (EAR), but it also applies to Web Application (WAR), Resource Adapters(RAR), and other JAR archived files, such as libraries, EJBs, and Java classes.

The following steps will walk you through the process to deploy the application. The WebLogic administrator usually assumes the deployer role in a production environment, so make sure to define a well-structured procedure to deploy the applications and follow it.

Getting ready

This recipe will deploy an archived application file called myApp.ear. The application will be target of the PROD_Cluster cluster instead of the individual Managed Servers.

How to do it...

Carry out the following steps:

  1. Create a new directory to be the application installation directory using the syntax/oracle/applications/<environment>/<application>/<version>:

    [[email protected]]$ mkdir -p /oracle/applications/prod/myApp/v1
    [[email protected]]$ cd /oracle/applications/prod/myApp/v1
    
  2. Create two directories:

    [[email protected]]$ mkdir app
    [[email protected]]$ mkdir plan
    
  3. Copy the myApp.ear file to the app directory.

  4. Access the Administration Console with your web browser at http://prod01.domain.local:7001/console.

  5. Click on the Lock & Edit button to start a new edit session.

  6. Navigate to the Deployments page by clicking on the link in the domain structure.

  7. Click on the Install button to install a new application.

  8. Type the path /oracle/applications/prod/myApp/v1/app and click on Next.

  9. Select myApp.ear from the list and click on Next.

  10. Select Install this deployment as an application and click on Next.

  11. Select the All servers from the cluster radio button from the PROD_Cluster cluster and click on Next.

  12. Leave the default options and click on the Finish button.

  13. A new deployment plan file will automatically be created in /oracle/applications/prod/myApp/v1/plan/Plan.xml.

  14. Click on the Activate Changes button to apply the changes.

  15. The application should be in a Prepared state. Start the application by selecting the myApp checkbox and clicking on the Start button with the Servicing all requests option.

How it works...

This procedure installs a simple enterprise application named myApp to the cluster PROD_Cluster in the WebLogic domain.

The application is distributed to the cluster using the default deployment option stage mode. In the stage mode deployment, the Administration Server prepares the myApp.ear file to be copied to the stages directory of each of the Managed Servers of the cluster PROD_Cluster. The directory is $DOMAIN_HOME/servers/<servername>/stage/<application>.

WebLogic will use this local copy until a new redeployment is made.

There's more...

There are many options to achieve the same results when deploying.

Deploying using the weblogic.Deployer tool

You can use the command-line tool weblogic.Deployer to make deployment changes in a WebLogic domain.

To perform the same deployment of myApp.ear to the PROD_Cluster cluster, do the following:

  1. Go to the WebLogic domain's bin directory:

    [[email protected]]$ cd $DOMAIN_HOME/bin
    
  2. Set the environment variables:

    [[email protected]]$ . ./setDomainEnv.sh
    
  3. Run the weblogic.Deployer command line with the parameters:

    [[email protected]]$ java weblogic.Deployer -adminurl t3://prod01.domain.local:7001 -username wlsadmin -password <pwd> -deploy -targets PROD_Cluster /oracle/applications/prod/myApp/v1/app/myApp.ear
    
  4. The following should be the output:

    weblogic.Deployer invoked with options:  -adminurl t3://prod01.domain.local:7001 -username wlsadmin -deploy -targets PROD_Cluster /oracle/applications/prod/myApp/v1/app/myApp.ear
    <Info><J2EE Deployment SPI><BEA-260121><Initiating deploy operation for application, myApp [archive: /oracle/applications/prod/myApp/v1/app/myApp.ear], to PROD_Cluster .>
    
  5. The myApp application should be deployed to the PROD_Cluster cluster.

Deploying applications using WLST

Now let's deploy the application through WLST using the following steps:

  1. Log in as a wls user to shell and start WLST:

    [[email protected]]$ $WL_HOME/common/bin/wlst.sh
    
  2. Connect to the Administration Server using wlsadmin as the user, <pwd> as the password, and t3://prod01.domain.local:7001 as the server URL:

    wls:/offline>connect("wlsadmin","<pwd>","t3://prod01.domain.local:7001")
    
  3. Run the following WLST command to deploy the myApp.ear application to the PROD_Cluster cluster:

    deploy("myApp", "/oracle/applications/prod/myApp/v1/app/myApp.ear","PROD_Cluster")
    
  4. The following should be the output:

    Deploying application from /oracle/applications/prod/myApp/v1/app/myApp.ear to targets PROD_Cluster (upload=false) ...
    <Apr 6, 2013 11:02:24 PM BRT><Info><J2EE Deployment SPI><BEA-260121><Initiating deploy operation for application, myApp [archive: /oracle/applications/prod/myApp/v1/app/myApp.ear], to PROD_Cluster .>
    .Completed the deployment of Application with status completed
    Current Status of your Deployment:
    Deployment command type: deploy
    Deployment State       : completed
    

About the Author

  • Dalton Iwazaki

    Dalton Iwazaki lives in Sao Paulo, Brazil and started working with technology in 1994 in a school lab, at the age of 17. As a system administrator, Dalton configured and maintained the network (Novel 3.12), the computers (Window 3.11, Windows NT 4.0, Windows 95), and the Internet. He also took his first steps in programming by building the school website in ASP and a computer voting system to simulate the election process in Delphi. In 1999, Dalton moved to a new company and started working with Java development. During this period, he worked on many Java server-side applications and dug deep to understand the use of JDBC, JMS, JMX, XML, and multithreaded applications. He built some frameworks from scratch to help the development, and started working on the Application Server world with IBM Websphere, Resin, Tomcat, JBoss, and BEA WebLogic. Until 2004, Dalton moved around to other companies working either as a Java developer or Java Architect. In 2004 and 2005, Dalton worked as a Software Development Manager; he lead 10 developers to build the entire website, provisioning and back office operations of a new ISP Provider with a variety of integrations and languages, such as Java, VB, C#, Perl, and PHP. Dalton then moved to a large international bank to work as a project manager in 2005 and 2006. His role was to manage the Internet Banking and Credit Card portals and integrate the business clients and the development team. From 2006 to 2008, Dalton started and worked on his own company, a design agency focused on the delivery of web solutions. In 2008, Dalton started working in partnership with Oracle Consulting on the infrastructure level of the WebLogic Server. In the following year, Dalton started a new company named VN Tecnologia, an IT professional services provider and Oracle Partner Network member. Working together with Oracle's clients and projects, Dalton's solid expertise in infrastructure and Java development are a rare combination used in his specializations - WebLogic Server configuration, administration, troubleshooting, and tuning. You can reach Dalton Iwazaki at [email protected]

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now