BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
| WebLogic Server Doc Home | Partners' Guide | Previous Topic | Next Topic | Contents | View as PDF

Creating Custom WebLogic Server Installations

The following sections highlight WebLogic Server configuration topics for partners and ISVs who wish to install a customized version of WebLogic Server for use with their applications:

- Overview

- Customizing the config.xml File

- Customizing the fileRealm.properties File

- Example Configuration

Overview

A WebLogic Server config.xml file provides configuration information for a given WebLogic Server management domain. The file controls all details of a given domain, including the name, number and configuration of servers and cluster; the list of deployable resources and applications; and the mapping of deployable resources and applications to servers and clusters.

The sections that follow describe typical modifications that a partner might want to make to config.xml in order to install a customized WebLogic Server management domain. If you are unfamiliar with the role of the config.xml file or management domains, see the Overview of WebLogic Server Management and Configuring WebLogic Servers and Clusters in the BEA WebLogic Server Administration Guide.

Note that under normal circumstances, BEA does not recommend editing the config.xml by hand. Partners, however, may need to edit this file directly in order to customize an installation. If you are unfamiliar with editing config.xml directly, see the BEA WebLogic Server Configuration Reference, which provides conventions for editing config.xml as well as a complete DTD description for the file.

Customizing the config.xml File

While the silent installation properties file defines initial location, password, and fileset for WebLogic Server, the config.xml file defines the majority of configuration settings for all WebLogic Servers in a management domain. The WebLogic Server tools, such as the console and weblogic.Admin utility, administer a domain's configuration by editing elements of the config.xml file.

Partners and ISVs can use custom config.xml files to create default WebLogic Server domain configurations that support their respective web applications. Typically this involves creating, modifying, or generating a config.xml file to:

- Pre-configure WebLogic Server resources that the application requires, or

- Automatically deploy components of the partner application into WebLogic Server

The following sections highlight elements of the config.xml file that partners might modify for their installations.

Pre-Configuring Application Resources

Partner applications typically rely on several WebLogic Server resources, each of which is defined in the config.xml file:

Resources | config.xml Elements | Notes
--- | --- | ---
Domain | Domain | To act as a cohesive unit, all WebLogic Servers that host a component of your application must reside within a single WebLogic Server administrative domain. The selection of a domain name also has an effect on the installed location of application components and the config.xml file itself: config.xml, fileRealm.properties, startup classes, and possibly your application components will reside within a subdirectory having the same name as the domain.
Server Names and Connection Information | Server | At the most basic level, partner applications may be configured to access one or more WebLogic Server names, IP addresses, and/or port numbers. If necessary for your application, you can hard-code a WebLogic Server domain to use specific server names and connection ports. IP Addresses can be configured dynamically by the application installer and embedded into a config.xml before installing the configuration.
JDBC Datasources | JDBCConnectionPool JDBCDataSource JDBCMultiPool JDBCTxDataSource | Partner applications that install WebLogic Server also frequently install an RDBMS or other datastore for maintaining the application data. If your product installer installs a datastore along with the application, you may want to pre-configure the installed WebLogic Server to setup a default datasource and connection pool for the datastore.

Deployment of Application Components

Partner applications can also be installed by adding the necessary elements to config.xml. Installing an application into a pre-configured WebLogic Server, however, requires coordination between the config.xml settings and the installed location of application component files (.war, .jar, .html and so forth).

The table below provides a summary of elements used to pre-deploy application components within WebLogic Server. See Example Configuration below for an example of how these elements correspond to the installed location of actual application component files.

Components | config.xml Elements | Notes
--- | --- | ---
Startup Classes | StartupClass | WebLogic Server startup classes can be used to initialize resources required by other components of the partner application.
Webserver | WebServer | Web applications typically require standard web resources, such as static .html content, in addition to business logic. Use the config.xml file to configure the default location of these static files for the application.
Web Applications | Application | EAR and WAR files can be stored anywhere in your application directory or the WebLogic Server directory. Reference the final installed location from within config.xml to deploy the application on startup.

Customizing the fileRealm.properties File

fileRealm.properties defines the ACLs, groups, and security principles for the default WebLogic Server file realm. If your application's security needs do not require a third-party security realm, you can pre-configure all necessary security constructs using fileRealm.properties.

If your applications requires integration with a third-party security realm (for example, single sign-on using the Windows NT security realm), you must configure both the fileRealm.properties file and a caching realm to use with the third-party security implementation. In this case, the fileRealm.properties configuration is used as a backup realm. This type of security implementation requires pre-configuration of both fileRealm.properties and config.xml.

Example Configuration below provides a simple example of a customized fileRealm.properties file. See Programming WebLogic Server Security.

Example Configuration

Sun's Java Pet Store application, as installed with WebLogic Server, provides a simple example of how to pre-configure an installation to support a web application. After installing WebLogic Server, a customer can easily begin using the Pet Store application simply by starting the server in the associated petstore domain.

This section highlights key aspects of the Pet Store application, and describes where those aspects are pre-configured using WebLogic Server configuration files.

Domain Configuration

The config.xml file opens with a new domain configuration for the petstore domain. All of the application's servers, resources, and components are deployed within this domain:

>     <Domain

>       Name="petstore"

>       >

The domain selection also affects the installed location of the preconfigured config.xml and fileRealm.properties files—WebLogic Server looks for a domain's configuration files in a /config/domain_name subdirectory of the server installation directory. Application components can be installed outside of the WebLogic Server directory and referenced from within config.xml.

Basic Server Setup

The Pet Store application utilizes a single server named petstoreServer. The connection properties for this server are preconfigured in the Server element attributes as follows:

>     <Server

>         JavaCompiler="C:\bea\jdk131/bin/javac"

>         ListenPort="7001"

>         Name="petstoreServer"

>         RootDirectory="C:\bea\wlserver6.1"

>         ThreadPoolSize="15"

>         TransactionLogFilePrefix="config/petstore/logs/"

>         IIOPEnabled="false"

>       >

The remainder of the server setup configures the default Web Server and security configuration for the Pet Store application. For example, Pet Store defines the default web application name "tour" to be used with the server:

>         <WebServer

>           DefaultWebApp="tour"

>           LogFileName="./config/petstore/logs/access.log"

>           LoggingEnabled="true"

>           Name="petstoreServer"

>         />

Because the Pet Store application can utilize SSL, the installed config.xml file enables SSL for the server, and specifies default locations for certificate and log files:

>         <SSL

>           CertificateCacheSize="3"

>           Enabled="true"

>           ListenPort="7002"

>           ServerCertificateChainFileName="./config/petstore/ca.pem"

>           ServerCertificateFileName="./config/petstore/democert.pem"

>           ServerKeyFileName="./config/petstore/demokey.pem"

>           TrustedCAFileName="./config/petstore/ca.pem"

>     Ciphersuites="SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_E
>     XPORT_WITH_DES_40_CBC_SHA,SSL_NULL_WITH_NULL_NULL"

>         />

>         <Log

>           FileName="./config/petstore/logs/weblogic.log"

>         />

>       </Server>

Application JDBC Requirements

The Pet Store application uses a single JDBC pool to access three different datasources. The installed config.xml file defines the pool and uses the default Pet Store server, petstoreServer, as the target for all datasources. Although the Pet Store application does not specify a default username and password for the connection pool, your application installer can prompt for a default username and password and set the config.xml elements as necessary:

>     <JDBCDataSource

>         JNDIName="jdbc.EstoreDB"

>         Name="EstoreDB"

>         PoolName="petstorePool"

>         Targets="petstoreServer"

>       />

>       <JDBCDataSource

>         JNDIName="jdbc.InventoryDB"

>         Name="InventoryDB"

>         PoolName="petstorePool"

>         Targets="petstoreServer"

>       />

>       <JDBCDataSource

>         JNDIName="jdbc.SignOnDB"

>         Name="SignOnDB"

>         PoolName="petstorePool"

>         Targets="petstoreServer"

>       />

>     ...

>     <JDBCConnectionPool

>         CapacityIncrement="1"

>         DriverName="COM.cloudscape.core.JDBCDriver"

>         InitialCapacity="1"

>         MaxCapacity="1"

>         Name="petstorePool"

>         Properties="user=none;password=none;server=none"

>         Targets="petstoreServer"

>         URL="jdbc:cloudscape:petStore"

>       />

Security Realm Definition

Because the Pet Store application uses the default WebLogic Server file realm, the installed config.xml file simply references the default realm name. Actual ACLs, groups, and so forth are defined in fileRealm.properties:

>     <FileRealm

>         Name="myFileRealm"

>       />

>       <Security

>         Realm="myRealm"

>       />

>       <Realm

>         FileRealm="myFileRealm"

>         Name="myRealm"

>       />

Application Components

The Pet Store application installs three application component files: tour.war, petstore.ear, and petstoreAdmin.ear. These components are each installed within the WebLogic Server subdirectory and deployed to petstoreServer. For example, tour.war is deployed using the following element:

>     <Application

>         Name="tour"

>         Path="C:\bea\wlserver6.1/config/petstore/applications/tour.war">

>         <WebAppComponent

>           Name="tour"

>           Targets="petstoreServer"

>           URI="tour.war"

>         />

>       </Application>

Notice that the c:\bea\wlserver6.1 portion of the application component path is determined during the WebLogic Server installation, while the remaining portion of the path is hard-coded. Your application installer can use a similar technique to install application components in a subdirectory unrelated to WebLogic Server, if necessary.

Startup Classes

On Windows systems, the Pet Store application uses a startup class to initiate the system web browser after the petstoreServer is booted. The definition for this startup class is mostly hard-coded in the installed config.xml file; only the port number is set dynamically by the WebLogic Server installation program:

>     <StartupClass

>         Arguments="port=7001"

>         ClassName="com.bea.estore.startup.StartBrowser"

>         FailureIsFatal="false"

>         Name="StartBrowser"

>         Targets="petstoreServer"

>         Notes="On Windows, this class automatically starts a browser after the server
>     has finished booting."

>       />

Example fileRealm.properties

Finally, default ACLs, groups, and principles are defined within the installed fileRealm.properties. In the case of the Pet Store application, all information in fileRealm.properties is hard-coded. Your application can prompt for and install custom groups and principals, as well as hard-code necessary information, as necessary:

>     acl.modify.weblogic.jndi.weblogic.fileSystem=everyone

>     user.j2ee=0xe22513c99d9279bdf9318894033ef310b9aa830f

>     acl.lookup.weblogic.jndi.weblogic.fileSystem=everyone

>     acl.lookup.weblogic.jndi.weblogic.ejb=system,everyone

>     acl.lookup.weblogic.jndi=system,everyone

>     acl.list.weblogic.jndi.weblogic.rmi=system,everyone

>     acl.lockServer.weblogic.admin=system,guest

>     acl.shutdown.weblogic.admin=system,guest

>     group.gold=

>     acl.boot.weblogic.server=system,everyone

>     user.jps_admin=0xcc0b7594b451623dd59a3db8148de6984c60ac74

>     ...

Note that user passwords are encrypted within fileRealm.properties. To hard code user passwords, use the Administration Console to add required users to the file, then use the generated file as a template for the installed fileRealm.properties.

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.