Domain configuration -III

Domain configuration part-1
Domain Configuration part-II

Configuring the JMS File Store

These screenshots configure the optional Java Messaging System (JMS). A JMS file store is a disk-based file in which persistent messages can be saved.

You can modify the JMS file stores that are configured in your domain on the Configure JMS File Stores page, which is displayed when you click Next on the Run Database Scripts page. This step is optional.

Review the current list of JMS file stores. The default values may vary based on the domain source that you selected earlier.

Note: The wizard provides two display modes: a concise tabular view of all the defined components and an individual view, in which each component is represented by a tab. You view a particular component by clicking the corresponding tab. To toggle the display mode between table and tab formats, click Switch Display.

Modify the settings as required for your domain.

Name: Enter a name for the JMS file store. The name must be a string of characters and can include spaces. The name of the JMS file store must be unique among all the component names within the domain.

Directory: Enter the path of the directory (in your system) in which the JMS file store resides. 

 

 

Synchronous write policy: From the list, select one of the following synchronous write policies to determine how the file store writes data to the disk:

•Cache-Flush: Transactions cannot be completed until all their write operations have been flushed to disk.

•Direct-Write: Write operations are performed directly to disk. Direct I/O is supported on most platforms. For a potential performance boost, file stores in direct I/O mode will automatically load a native I/O wlfileio2 driver. This driver is available on Windows, Solaris, HP, AIX, and Linux platforms. If this policy is active on an unsupported platform, the file store switches automatically to the cache-flush policy.

•Disabled: Transactions are complete as soon as the writes are cached in memory. When this policy is active, completion of transactions does not depend on waiting for writes to reach the disk.

This setting affects performance, scalability, and reliability.

Note: The use of the direct-write policy is transactionally reliable in Solaris systems, but Windows systems may leave transaction data in the on-disk cache without writing it to disk immediately. This is not considered to be transactionally reliable because a power failure can cause loss of on-disk cache data, possibly resulting in lost or duplicate (or both) messages. For reliable writes using direct-write on Windows, either disable all write caching for the disk (enabled by default) or use a disk with a battery-backed cache. Some file systems, however, do not allow this value to be changed (for example, a redundant array of inexpensive disks (RAID) disk system that has a reliable cache).

If the JMS file store is used exclusively for paging nonpersistent messages to disk, the synchronous write policy is ignored.

Customizing Application and Service Targeting Configuration

 if you want to go down an optional path to configure more parameters. By default, both of these screens have No selected. If you leave it as No, you will skip the next few screens.

Configuring RDBMS Security Store Database

By default, database security is disabled—that is, all users, groups, and roles are stored in the embedded Lightweight Directory Access Protocol (LDAP) store of the administration server and this panel is disabled.

If you choose to use any of the supported databases to store this information, select the database type and populate the DBMS name, host and port, and username and password. The remaining fields are prepopulated for you based on this information. Before you start the server, you must load the necessary SQL scripts (<WL_HOME>/server/lib) for the RDBMS security store.

The following RDBMS systems can be used for the RDBMS security store:

•Oracle 9i Release 9.0.1 and 9.2.0

•Oracle 10g, Oracle 11g

•MS-SQL 7.0, 2000, and 2005

•DB2

•PointBase RDBMS 4.x and 5.x included in Oracle WebLogic Server

•Sybase

•MySQL

•Informix

•Ingres

See WebLogic Release notes for particular versions supported from other vendors.

Note: The Configuration Wizard has been modified to allow you to create the RDBMS security store when you create a domain. When you boot the domain, you can set additional configuration options for the RDBMS security store from the WebLogic Administration Console.

Oracle WebLogic Server provides a set of SQL scripts for each supported RDBMS system that must be run before booting the domain. These scripts create the tables in the data store that are used by the security providers.

Oracle WebLogic Server provides the option of using an external RDBMS as a data store that is used by the following security providers:

•XACML Authorization and Role Mapping providers

•WebLogic Credential Mapping provider

•PKI Credential Mapping provider

•The following providers for SAML 1.1:

-SAML Identity Assertion provider V2

-SAML Credential Mapping provider V2

•The following providers for SAML 2.0:

-SAML 2.0 Identity Assertion provider

-SAML 2.0 Credential Mapping provider

•Default Certificate Registry

The RDBMS security store is required if you want to use SAML 2.0 services in two or more Oracle WebLogic Server instances in a domain. Security store helps implement Single Sign On (SSO) between systems.

Reviewing the WebLogic Domain

The screenshot shows the summary so far. The choices in the Summary View drop-down list are the following:

•Deployment

•Application

•Service

•Cluster

•Machine

•JMS Server

 

 

Creating the WebLogic Domain

 The domain directory can be located anywhere in the system. By default, it resides in <MW_HOME>/user_projects/domains/DOMAIN_NAME, where <MW_HOME> is the directory that contains the product installation, and DOMAIN_NAME is the name of the domain directory defined by the selected template.

The Configuration Wizard stores the config.xml file and all other generated components in the domain directory that you specify.

Note: You cannot overwrite an existing domain. If a domain with the name that you specify exists in the selected location, you must either delete the existing domain, or specify a different name or location for the new domain.

Domain Directory Structure

The domain directory also contains the following directories:

•tmp: A directory for temporarily storing files. You should not modify any files in this directory.

•user_staged_config: This directory is an alternative to the config directory if the domain is set up such that the configuration information is “user-staged”—that is, the administrator is responsible for staging (copying to the managed servers) the configuration information.

•pending: This directory contains the domain configuration files that represent the configuration changes that have been requested, but not yet been activated. After the configuration changes are activated, the configuration files are deleted from this directory.

•servers: The servers directory that contains the subdirectories for the administration and managed servers is created the first time the servers are started. This directory contains one subdirectory for each Oracle WebLogic Server instance in the domain. The subdirectories contain data that is specific to each server instance.

•lib: Any JAR files that you put in this directory are added to the Java system CLASSPATH of each server instance in the domain when the server’s Java Virtual Machine starts.

•init-info: This directory contains files that are used for WebLogic domain provisioning. You should not modify any files in this directory.

 

•security: This directory holds the security-related files that are the same for every Oracle WebLogic Server instance in the domain: SerializedSystemIni.dat

-This directory also holds the security-related files that are needed only by the domain’s administration server:

DefaultAuthorizerInit.ldift

DefaultAuthenticatorInit.ldift

DefaultRoleMapperInit.ldift

•console-ext: This directory contains extensions to the Administration Console, which enable you to add content to Oracle WebLogic Server Administration Console, replace content, and change the logos, styles, and colors without modifying the files that are installed with Oracle WebLogic Server. For example, you can add content that provides custom monitoring and management facilities for your applications.

•config: This directory contains the current configuration and deployment state of the domain. The central domain configuration file, config.xml, resides in this directory. Ignore the /lib directory under /config.

•bin: This directory contains the scripts that are used for starting and stopping the administration server and the managed servers in the domain. These scripts are generally provided as .sh files for UNIX and .cmd files for Windows. The bin directory can optionally contain other scripts of domainwide interest, such as scripts to start and stop database management systems, full-text search engine processes, and so on.

•autodeploy: This directory provides a quick way to deploy applications in a development server. When the Oracle WebLogic Server instance runs in development mode, it automatically deploys any applications or modules that you place in this directory.

The files that you place in this directory can be Java EE applications, such as:

•An EAR file

•A WAR, EJB JAR, RAR, or CAR archived module

•An exploded archive directory for either an application or a module

domain-name: The name of this directory is the name of the domain.

JVM Run-Time Arguments

You can see the default memory sizes used to start the WebLogic environment by entering echo $MEM_ARGS. You specify the startup minimum heap size with the –Xms flag. The startWebLogic utility gives a default value –Xms256m (that is, 256 megabytes). You specify the maximum heap size with the –Xmx flag. The startWebLogic utility gives a default value
–Xmx512m (that is, 512 megabytes). 

Options can be set using the –D options. startWebLogic, for example, has an option that sets the policy file.

Oracle WebLogic Server Dependencies

The PATH environment variable provides the list of directories that your operating system uses to search for executable programs. Because the JVM is an executable program, the directory containing the virtual machine should be included in the PATH environment variable. 

CLASSPATH is the list of directories that the virtual machine uses to search for dependent classes in a program. You can set CLASSPATH in an environment variable or as a command-line parameter when you execute the virtual machine.

Configuring CLASSPATH

In Oracle WebLogic Server 10.3, only two files need to be configured in CLASSPATH: weblogic.jar and weblogic_sp#.jar (if it exists), which are the primary distribution files and the service pack, respectively. You can optionally include other files in CLASSPATH depending on whether or not you would be using Java EE Connector Architecture (JCA) connectivity or another database.

Also, in order for the virtual machine to locate the class, the root directory of the package should be included in CLASSPATH. The root directory is included because the virtual machine knows which subdirectories to look under when it sees the fully qualified name of the class. Only root class directories and JAR files should be in the Java system CLASSPATH.

If you built a class named AWorkingClass.class and if the class is in a package named com.bea.examples and the file is located at  c:\student\files\com\bea\examples\AWorkingClass.class, your CLASSPATH should include c:\student\files\ to execute the java com.bea.examples.AWorkingClass program.

After installation, Oracle WebLogic Server’s CLASSPATH is already set, but you may choose to modify it for a number of reasons such as adding a patch to Oracle WebLogic Server, updating the version of PointBase that you are using, or adding support for Log4j logging.

To apply a patch to all your Oracle WebLogic Server domains without the need to modify the CLASSPATH of a domain, give the patch JAR file the name, weblogic_sp.jar, and copy it into the <WL_HOME>/server/lib directory. The commEnv.cmd/sh script automatically includes a JAR named weblogic_sp on the CLASSPATH for you.

If you would rather not use the name weblogic_sp.jar for your patch file or you would just like to ensure that a JAR file, such as the one mentioned as follows, comes before weblogic.jar on the CLASSPATH, perform the following:

•For all domains, edit the commEnv.cmd/sh script in <WL_HOME>/common/bin and prepend your JAR file to the WEBLOGIC_CLASSPATH environment variable.

•To apply a patch to a specific Oracle WebLogic Server domain, edit the setDomainEnv.cmd/sh script in that domain’s bin directory and prepend the JAR file to the PRE_CLASSPATH environment variable.

If you use the trial version of PointBase, an all-Java database management system, include the following files on the CLASSPATH:

•<WL_HOME>/common/eval/pointbase/lib/pbembedded51.jar and pbclient51.jar

If you use WebLogic Enterprise Connectivity, include the following files on the CLASSPATH:

•<WL_HOME>/server/lib/wlepool.jar

•<WL_HOME>/server/lib/wleorb.jar

If you use Log4j logging, include the following file on the CLASSPATH:

•<WL_HOME>/server/lib/log4j.jar: The shell environment in which you run a server determines which character you can use to separate the path elements. On Windows, you typically use a semicolon (;). In a BASH shell, you typically use a colon (:).

Syntax

The syntax for invoking weblogic.Server is as follows:

java [options] weblogic.Server [-help]

 

Starting the Administration Server Using the Start Menu in Windows

When you create an administration server on a Windows computer, the Configuration Wizard creates a shortcut on the Start menu for starting the server. (The menu option is: User Projects > DOMAIN_NAME > Start Admin Server for WebLogic Domain.) The command that the Configuration Wizard adds to the Start menu opens a command page and calls the startup script (startWebLogic.cmd).

Starting Administration Server Using startWebLogic.sh

Navigate to the directory in which you located the domain. By default, this directory is <MW_HOME>/user_projects/domains/DOMAIN_NAME, where DOMAIN_NAME is the root directory of the domain. (The name of this directory is the name of the domain.) Run one of the following scripts:

•bin\startWebLogic.cmd (Windows)

•bin/startWebLogic.sh      (UNIX and Windows. On Windows, this script supports the MKS and Cygnus BASH UNIX shell emulators.)

Replace the username (default is weblogic) and password (shown as asterisks) as appropriate.

The startWebLogic script performs the following steps:

1.  It sets the environment variables by invoking DOMAIN_NAME/bin/setDomainEnv.sh (or .cmd), where DOMAIN_NAME is the directory in which you located the domain—for example, <WL_HOME>/user_projects/domains/DOMAIN_NAME, where <WL_HOME> is the location in which you installed Oracle WebLogic Server. The setDomainEnv script sets environment variables such as WL_HOME, BEA_HOME, SUN_JAVA_HOME, JAVA_HOME, SAMPLES_HOME, DOMAIN_HOME, PRODUCTION_MODE, PROXY_SETTINGS, MEM_ARGS, CLUSTER_PROPERTIES, JAVA_PROPERTIES, JAVA_OPTIONS, CLASSPATH, PRE_CLASSPATH, POST_CLASSPATH, and others. The setDomainEnv script has no screen output.

2.  It invokes the java weblogic.Server command, which starts a JVM that is configured to run an Oracle WebLogic Server instance.

When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command page):

<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>

 

Stopping the Administration Server

Stopping the WebLogic part of the domain can be done in several ways:

•If the process is running in a terminal session, you can press Ctrl + C to stop the process.

•The domains/DOMAIN_NAME/bin/stopWebLogic.sh script will shut down only the administration server.

•You can shut down servers using the Administration Console, including the administration server.

The Middleware environment may consist of more than just the domain. It may consist of other components that are not managed from the Administration Console—for example, the Oracle HTTP Server and Web Cache. Those non-Java components may be managed by Oracle Process Manager and Notification (OPMN ), which has its own mechanisms for graceful shutdowns.

There is no single command to stop a whole domain; you have to stop the individual components separately. Nevertheless, this is a very good script to create for yourself early in the rollout of a domain.