Part - 3 Oracle WebLogic Server 12c: Administration I - 1Z0-133 -

Oracle WebLogic Server 12c: Administration I - 1Z0-133 - Part - 3

SERVERS

Standard Startup

java weblogic.Server

Available Methods to start servers

1. Using startup scripts
2. Using WLST and Node Manager
3. Using the Administration Console and Node Manager

Standard Scripts

When a WebLogic Server domain is created, it includes the following scripts^[3], which are used in the standard process of starting and shutting down server instances:

• startWebLogic
• startManagedWebLogic
• setDomainEnv
• setStartupEnv
• The script sets the STARTUP_GROUP variable to AdminServerStartupGroup if the value of the SERVER_NAME variable is AdminServer. Then, it will ensure that the POST_ CLASSPATH variable includes the following library:

  
  

  WL_HOME/oracle_common/modules/com.oracle.cie.config-wls-online_8.1.0

• setWLSEnv
• commEnv
• 
  

  
  
  
  

  
  
  The script checks whether both the WL_HOME and MW_HOME variables are set. If they are not, it will display an error message and exit with a status code of 1. Then, if only the MW_HOME has not been set, it will define it with a value of one directory above of that which the MW_HOME directory points to and source itself again to ensure these variables are set.

The first four scripts are part of the domain configuration and are found in the DOMAIN_HOME/bin directory, and the last two are located in the ORACLE_HOME/wlserver/bin and ORACLE_HOME/wlserver/common/bin directories, respectively. 

The order in which the standard scripts are invoked to build the command to start a server instance.

Path, Classpath, and System Properties

As shown in previous sections, the standard configuration settings of a WebLogic Server instance are defined in both, environment variables and system properties. In a WebLogic Server instance, several system properties are defined that are product specific. Other system properties and some environment variables are commonly defined for any Java program. These include the PATH and CLASSPATH variables.

The PATH variable in WebLogic Server has the same purpose as it does in any non- Java environment. It is defined to include a series of directories that contain binaries. After setting this variable, such binaries will be conveniently available to be run without having to type the full path to their location.

The CLASSPATH variable is defined specifically for every Java program. It is meant to tell the JVM where to find the classes required to run an application of a certain type, such as a WebLogic Server instance. CLASSPATH entries can include specific JAR files or directories with wildcards to include files without stating their individual names. The order in which CLASSPATH entries are included does matter in case of duplicate JAR files. The first one that is found will be used and the rest will be ignored.

There are two simple ways to inspect the startup configuration of a server instance, either looking at the corresponding server log file or by using a tool to interrogate the JVM for these settings.

As explained before, there will be messages that output the content of the PATH, CLASSPATH, and JAVA_OPTIONS variable. This latter variable will include the system properties and values that have been set.

There are several tools that can be used to interrogate the JVM such as jcmd and jstat, both of which are included in the Oracle JDK. The jcmd tool is a pretty simple but powerful tool for inspecting the JVM configuration and can also perform other important tasks on the server process.

Sample CLASSPATH Value

 Default value of the CLASSPATH variable from the log file of an administration server

---

CLASSPATH=/usr/java/jdk1.7.0_80/lib/tools.jar:/home/gustavo/Mine/apress/
lab/product/wlserver/server/lib/weblogic_sp.jar:/home/gustavo/Mine/apress/
lab/product/wlserver/server/lib/weblogic.jar:/home/gustavo/Mine/apress/lab/
product/wlserver/../oracle_common/modules/net.sf.antcontrib_1.1.0.0_1-0b3/
lib/ant-contrib.jar:/home/gustavo/Mine/apress/lab/product/wlserver/modules/
features/oracle.wls.common.nodemanager_2.0.0.0.jar:/home/gustavo/Mine/
apress/lab/product/wlserver/../oracle_common/modules/com.oracle.cie.config-
wls-online_8.1.0.0.jar:/home/gustavo/Mine/apress/lab/product/wlserver/
common/derby/lib/derbyclient.jar:/home/gustavo/Mine/apress/lab/product/
wlserver/common/derby/lib/derby.jar:/home/gustavo/Mine/apress/lab/product/
wlserver/server/lib/xqrl.jar

---

The code above shows that the CLASSPATH variable includes the following JAR files by name:

• tools.jar
• weblogic.jar
• weblogic_sp.jar
• ant-contrib.jar
• com.oracle.cie.config-wls-online_8.1.0.0.jar
• oracle.wls.common.nodemanager_2.0.0.0.jar
• derbyclient.jar
• derby.jar
• xqrl.jar

How the CLASSPATH Is Built

In the sample system, the WebLogic Server classpath was built in the following specific sequence:

1. The com.oracle.cie.config-wls-online JAR is added to the POST_ CLASSPATH variable in the setStartupEnv script
2. The derbyclient and derby JARs are added to the DATABASE_ CLASSPATH variable in the setDomainEnv script
3. The POST_CLASSPATH is appended values from the DATABASE_ CLASSPATH in the setDomainEnv script
4. The xqrl JAR is added to the POST_CLASSPATH in the setDomainEnv script
5. The CLASSPATH variable is set to the value of the POST_ CLASSPATH variable in the setDomainEnv script
6. The WEBLOGIC_CLASSPATH variable is set to include the following JARs: tools, weblogic, weblogic_sp, ant-contrib and oracle.wls.common.nodemanager in the setDomainEnv script
7. The CLASSPATH variable is prepended the value of the WEBLOGIC_CLASSPATH in the setDomainEnv script
8. The CLASSPATH variable is defined to the same value in the startWebLogic script

ample System Properties

Listing 5-4: Default JVM flags and system properties from the log file of an administration server

---

Starting WLS with line:
/usr/java/jdk1.7.0_80/bin/java -server   -Xms256m -Xmx512m
-XX:CompileThreshold=8000 -XX:PermSize=128m  -XX:MaxPermSize=256m
-Dweblogic.Name=AdminServer -Djava.security.policy=/home/gustavo/Mine/
apress/lab/product/wlserver/server/lib/weblogic.policy  -Xverify:none
-Djava.endorsed.dirs=/usr/java/jdk1.7.0_80/jre/lib/endorsed:/home/
gustavo/Mine/apress/lab/product/wlserver/../oracle_common/modules/
endorsed -Xms4096m -Xmx4096m -da -Dwls.home=/home/gustavo/Mine/
apress/lab/product/wlserver/server -Dweblogic.home=/home/gustavo/Mine/
apress/lab/product/wlserver/server -Dweblogic.utils.cmm.lowertier.
ServiceDisabled=true weblogic.Server

---

The code above shows the following JVM flags:

• Xms and Xmx
• XX:CompileThreshold
• PermSize and MaxPermSize
• weblogic.Name
• java.security.policy
• Xverify
• java.endorsed.dirs
• wls.home
• weblogic.home
• weblogic.utils.cmm.lowertier.ServiceDisabled

The memory values shown in the previous listing are the standard values for an Oracle HotSpot JVM running on a 64-bit Linux OS and represent the contents of the MEM_ARGS variable in the standard scripts.

The heap size is set to range from 256 megabytes up to 512 megabytes, with a permanent generation size set to range from 128 megabytes to 256 megabytes. The CompileThreshold option is a performance flag to indicate that there should be 8000 method invocations or code iterations before code compilation. These values can be overridden in a setUserOverrides script. The actual heap size can be identified in the subsequent Xms and Xmx definition, which takes precedence over the first. It can also be reviewed by querying the JVM flags using the jcmd tool. The value of none in the Xverify flag disables bytecode verification. The java.security.policy specifies the location of the Java Security Manager policy file for WebLogic, which is the weblogic.policy file located in the server/lib directory of the product installation. The java.endorsed.dirs sets the location of the directory where libraries may be placed to override packages in the JDK. The weblogic.Name system property is set to the server name, in this case AdminServer. The wls.home and weblogic.home are both references to the WL_HOME directory.

The complete list of system properties defined in a running server instance the JVM may be obtained using a variety of methods, for instance, by using the VM.system_properties option of jcmd.

Additional System Properties

WebLogic Server defines a large set of additional system properties that can optionally be used to configure a server instance at startup. These properties can actually be used to override the server configuration that is kept in the domain repository. Unless persisted in the config.xml file, these settings would only last until the server instance is restarted.

As shown in  these system properties are specified in the command line using a capital D, followed by the property name and its intended value, such as:

-Dweblogic.Name=AdminServer

The following list of properties is a small subset of the full range of options available. The purpose of each can be derived from their names:

• weblogic.Domain
• weblogic.ProductionModeEnabled
• weblogic.management.server
• weblogic.Name
• weblogic.ListenAddress
• weblogic.ListenPort
• weblogic.ssl.ListenPort
• weblogic.security.SSL.minimumProtocolVersion
• weblogic.system.BootIdentityFile
• weblogic.log.FileName
• serverType

The weblogic.management.server specifies the URL that must be used to contact the administration server in a given domain. The serverType property can take a value of wlx in which case, the server instance will be a lightweight instance that will not load the EJB, JMX, and JCA subsystems.

The jcmd tool is part of the Oracle JDK set of tools. Help is available by running: jcmd PID help where PID is the number of a JVM process.

Recommended Exercises

1. Using the standard process start both an administration server and a managed server and review the contents of the CLASSPATH, PATH, MEM_ARGS, and command line used.
2. Manually set the CLASSPATH and start both an administration server and managed server passing the minimum necessary system properties for a WebLogic Server instance.
3. Implement a setUserOverrides script to customize the server configuration.
4. Manually start a server instance and verify if it applies the customizations from the setUserOverrides script.