Release Notes

 Previous Next Contents View as PDF  

WebLogic Server 7.0 Features and Changes

Welcome to BEA WebLogic Server 7.0 Service Pack 7! As the leading Web application server, WebLogic ServerTM implements J2EE 1.3 technologies, Web services, and other leading Internet standards to provide a reliable framework for highly available, scalable, and secure applications. WebLogic Server's seamless integration of disparate, heterogeneous platforms and applications enables your network to leverage existing software investments and share the enterprise-class services and data that are crucial to building mission-critical E-Business applications.

WebLogic Server documentation, including these release notes, is updated frequently at http://www.oracle.com/technology/documentation/index.html.

For deprecated features and APIs, see Deprecated APIs and Features in the WebLogic Server 7.0 Upgrade Guide.

The following sections describe the new features and major improvements made in the WebLogic Server 7.0 general release and its associated service packs.

 


What's New in WebLogic Server 7.0 SP7

WebLogic Server 7.0 SP7 offers the following important enhancements.

Administration Console

When WebLogic Server was executed as a Windows Service, applications located in remote mapped drives could not be deployed from the Console.

The set new Location option has been added to the Locate Application or Component to Configure page to enable you to deploy applications from a mapped network drive on Windows, using the UNC path.

Plug-Ins

 


What's New in WebLogic Server 7.0 SP6

BEA continues to support WebLogic Server 7.0 customers by providing WebLogic Server 7.0 service packs that resolve problems and introduce new features in WebLogic Server.

Administration Console

The Servlet Extension Case Sensitive attribute has been added to server and cluster configurations. In addition, the Web App Files Case Insensitive attribute has been added to security domain configuration.

These attributes specify whether file lookups for Java Server Pages (JSPs) are case sensitive on all platforms except win32; file lookups from standard win32 file systems are always case-insensitive. On case-insensitive file systems other than win32 (such as NT Samba mounts from UNIX or Mac OS that have been installed in case-insensitive mode), specify case insensitive lookups by setting these attributes to false to prevent the JSP from returning its source code. For example, if a JSP is being served from a Samba mount and you have specified case-insensitive lookups, WebLogic Server converts all file name extensions to lower case before looking up the JSP.

For more information, please review the security advisory at http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp.

WebLogic Tuxedo Connector

In WebLogic Server 7.0 SP6 and higher, you can configure an optional dedicated WTC thread pool to process all EJB applications rather than the default execute queue. See WebLogic Server Threads in the Weblogic Tuxedo Connector Administration Guide.

 


What's New in WebLogic Server 7.0 SP5

WebLogic Server 7.0 SP5 offers important enhancements.

Oracle 10g JDBC Thin Driver

In WebLogic Server 7.0SP5, the Oracle 10g (10.1.0.2.0) version of the Oracle Thin driver was added to the release and is now the default version of the Oracle Thin driver. See "Using Third-Party Drivers with WebLogic Server" in Programming WebLogic JDBC.

Note: The following are known issues with the Oracle 10g Thin driver:

JDBC MultiPool Failover Enhancements

In WebLogic Server 7.0SP5, the following enhancements were made to JDBC MultiPools:

See "MultiPool Failover Enhancements" in Programming WebLogic JDBC for more details.

JDBC Connection Pool Testing Enhancements

In WebLogic Server 7.0SP5, the following features were added to JDBC connection pools to improve the functionality of database connection testing for pooled connections and to minimize delays in connection request handling:

To enable these features, you add the attributes to the JDBCConnectionPool object in the config.xml file. Both attributes also require that the TestConnectionsOnReserve is set to true and a value is provided for TestTableName. See "JDBC Connection Pool Testing Enhancements" in Programming WebLogic JDBC for more information.

EJB Cache Size Trimming

You can now configure automatic trimming of idle read-write entity beans from your EJB cache. Automatic trimming prevents significant increases in the baseline memory footprint.

You configure cache size trimming by specifying the idle-timeout-seconds element with a value greater than zero. If no specification is made or the specified value is 0, automatic cache size trimming is not active and idle beans will not be periodically removed from the cache. For individual entity bean caches specified via the entity-cache tag in the weblogic-ejb-jar.xml deployment descriptor, the existing idle-timeout-seconds element will be enabled for those entity beans whose concurrency-strategy is set to Database, ReadOnly or Optimistic.

In addition to being applicable for individual entity caches via the entity-cache tag, this feature is also available for application caches where the idle-timeout-seconds is set via the entity-cache-ref tag.

Ant Tasks for Domain Configuration

In WebLogic Server 7.0SP5, the following Ant tasks were added to provide additional administration functionality for developers:

See Using Ant Tasks to Configure a WebLogic Server Domain in the Administration Guide for information about wlserver and wlconfig. See wldeploy Ant Task in Developing WebLogic Server Applications for information about wldeploy.

Configurable Log Rotation Criteria

Starting in Service Pack 5, if you have WebLogic Server installed as a Windows service, you can change the default time interval or use other criteria to archive the standard out and standard error logs. See Log File Rotation in the Administration Guide.

Enhanced Server Logs

You can configure the Administration Server to emit log messages when a user changes the configuration or invokes management operations on any resource within a domain. For example, if a user disables SSL on a Managed Server in a domain, the Administration Server emits log messages. These messages provide an audit trail of changes within a domain's configuration (configuration auditing).

Client Tracking

Beginning with Service Pack 5, it is possible to monitor the IP addresses of durable subscribers. This information is now available on the JMSConnectionRuntimeMBean.

Custom Auditing Provider

Beginning with Service Pack 5, the default security realm for WebLogic Server includes a WebLogic Auditing provider. The WebLogic Auditing provider records information for any changes to the WebLogic Server domain configuration. This includes attribute values that have been changed, edited, or removed, as well as operations that have been invoked. See Do You Need to Develop a Custom Auditing Provider in Developing Security Providers for WebLogic Server.

New Security API

Previously, although you could access the PrincipalAuthenticator.authenticate() method by calling weblogic.security.services.Authenticate.login(), there was no way to access the PrincipalAuthenticator.assertIdentity() method, which would be useful in situations where the user has received the token other than in an HTTP or HTTPS header (for example, in an argument to a fat client). A new API, weblogic.security.services.Authentication.assertIdentity(), enables you to access PrincipalAuthenticator.assertIdentity().

User Configuration and User Key Files for weblogic.Admin and Ant Tasks

For any weblogic.Admin command that connects to a WebLogic Server instance, you must provide user credentials. You can now use the new STOREUSERCONFIG command to encrypt the user credentials instead of passing credentials directly on the command line or storing unencrypted credentials in scripts.

Pausing and Resuming Message-Driven Beans

It is now possible to pause and resume MDBs.

WebDAV Support

WebLogic Server proxy plug-ins restrict the HTTP commands that can be submitted from the client to the server. The validation rules in the plug-in code now allow the following HTTP commands that are needed for WebDAV implementations:

DELETE

GET

HEAD

OPTIONS

POST

PUT

*COPY

LOCK

MKCOL

MOVE

PROPFIND

PROPPATCH

SEARCH

UNLOCK

 


What's New in WebLogic Server 7.0 SP4

WebLogic Server 7.0 Service Pack 4 (SP4) coincides with WebLogic Platform 7.0 SP4, which optimizes Service Pack content across all WebLogic Platform components. Customers using WebLogic Integration 7.0, WebLogic Portal 7.0, or the full Platform 7.0 and requiring a service pack update beyond SP2 should use Platform 7.0 SP4.

 


What's New in WebLogic Server 7.0 SP3

WebLogic Server 7.0 SP3 offers important enhancements.

WebLogic Server 7.0 Service Pack 3 and WebLogic Workshop

WebLogic Server 7.0 Service Pack 3 (SP3) includes service pack updates for Weblogic Server and WebLogic Workshop. A WebLogic JRockit SP3 is also available and can be used in conjunction with WebLogic Server 7.0 SP3.

WebLogic Server 7.0 SP3 is intended for WebLogic Server and WebLogic Workshop support customers. WebLogic Server 7.0 SP3 is available through upgrade installers from the BEA support site (http://support.bea.com). The WebLogic Server 7.0 SP3 upgrade installers will not allow SP3 to be applied to an existing WebLogic Integration 7.0, WebLogic Portal 7.0 or full WebLogic Platform 7.0 installation.

BEA continues to support Platform 7.0 customers by providing Platform 7.0 service packs that incorporate service pack updates for all Platform 7.0 components (WebLogic Server, WebLogic Workshop, WebLogic Integration, WebLogic Portal, and Weblogic JRockit).

JDBC Vendor Connection Access from Pooled Connection

With Service Pack 3, you now have access to the underlying JDBC vendor connection from a database connection in a WebLogic connection pool. Some vendor-specific JDBC extensions require access to the vendor connection. There is a performance cost when using a vendor connection because once the vendor connection is exposed, the pooled connection is never returned to the connection pool for reuse. BEA recommends that you do NOT use a vendor connection unless absolutely necessary.

See "Getting a Physical Connection from a Connection Pool" in Programming WebLogic JDBC.

XA JDBC Statement Caching Enhancements

The prepared statement cache feature was changed so that the cache behaves differently for connection pools that use an XA (transaction aware) JDBC driver to create database connections instead of a non-XA JDBC driver. For the XA prepared statement cache, WebLogic Server uses a least recently used (LRU) algorithm to determine which statements to store in the cache for each connection in the connection pool.

See "Increasing Performance with the Prepared Statement Cache" in the Administration Guide.

JDBC Connection Leak Detection Enhancements

Enhancements were made to the JDBC connection leak detection feature so that when an application does not properly close a database connection from a JDBC connection pool (this is known as leaking a connection), Weblogic Server automatically creates a file named server_nameslcn.tsf in the domain directory. The file lists the JDBC connection pool name from which the connection leaked and the stack trace where the connection was not closed. For any subsequent connection leaks, WebLogic Server appends the information to the file.

Support for Oracle Virtual Private Databases

WebLogic Server now provides support for Oracle Virtual Private Databases (VPDs). A VPD is an aggregation of server-enforced, application-defined fine-grained access control, combined with a secure application context in the Oracle 9i database server.

For more information, see "Programming with Oracle Virtual Private Databases" in Programming WebLogic JDBC.

JTA Transaction Log Write Policy

In WebLogic Server Service Pack 3, transaction log file write options were added to enable you to select the way entries are written to the transaction log. The option you select can affect server performance during transaction processing. Transaction log file write policy options are:

See "Setting the Transaction Log File Write Policy" in the Administration Guide.

Support for XAResource Transaction Timeout

The WebLogic Server Transaction Manager now supports setting a transaction branch timeout value on a participating XA resource if the resource manager supports the javax.transaction.xa.XAResource.setTransactionTimeout() method. You may want to set a transaction branch timeout if you have long-running transactions that exceed the default timeout value on the XA resource.

For the WebLogic Server Transaction Manager to set the transaction timeout on a JDBC XA resource, specify a value for the following properties in the JDBC connection pool tag in the config.xml file:

These properties apply to connection pools that use an XA JDBC driver to create database connections only. They are ignored if a non-XA JDBC driver is used.

When these values are set, the WebLogic Server Transaction Manager calls XAResource.setTransactionTimeout() as described above. The implementation of the method in the XA resource manager (for example, an XA JDBC driver) or the XA resource determines how the value is used. For example, for Oracle, the setTransactionTimeout() method sets the Session Timeout (SesTm), which acts as a maximum idle time for a transaction. The behavior may be different for other XA Resources.

The XASetTransactionTimeout and XATransactionTimeout properties are not available in the Administration Console. You must add them to the config.xml file while the domain is not active. For example:

<JDBCConnectionPool 
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
Name="oraclePool"
Password="{3DES}8YdvP4FQW3k="
Properties="user=SCOTT"
URL="jdbc:oracle:thin:@server:port:sid"
XASetTransactionTimeout="true"
XATransactionTimeout="120"/>

Removing Passivated EJBs from Disk

A new weblogic-ejb-jar.xml deployment descriptor element—session-timeout-seconds—specifies how long the EJB container waits before removing an idle stateful session EJB from disk. See session-timeout-seconds in Programming WebLogic Enterprise JavaBeans.

context-root Naming for Web Applications

When you deploy a Web application as part of an Enterprise Application (.EAR file or directory), the Web application component is named after the context-root value specified in the application.xml deployment descriptor. This value takes precedence over any context-root value specified in weblogic.xml, or the Web application's URI.

Controlling Access to the WSDL and Home Page of a Web Service

You can now control access to the WSDL and Home Page of a WebLogic Web Service by specifying the exposeWSDL and exposeHomepage attributes of the <web-service> element of the web-services.xml deployment descriptor file.

See Securing the WSDL and Home Page of a Web Service.

Changes to Security Realm Options

Changes were made to the security realm options in this release of WebLogic Server. The Ignore security data in deployment descriptors option was replaced by the Check Roles and Policies and Deployment Descriptor Security Behavior options. The Administration Console online help does not describe these new options. Refer to Creating a New Security Realm in Managing WebLogic Security and Techniques for Securing URL and EJB Resources in Securing WebLogic Resources for a description of these options.

 


What's New in WebLogic Server 7.0 SP2

The following sections contain important notes for BEA WebLogic Server 7.0 SP2.

Upgrade Installer Caveats

Note the following about the WebLogic Server 7.0SP2 upgrade installer:

Migrating Domains Created Using the Configuration Wizard

The Configuration Wizard is a WebLogic Platform tool that allows you to create new domains quickly and easily. If you have domains that you created with the Configuration Wizard in a WebLogic Server 7.0 or 7.0 SP1 environment, and you want to continue running them in a WebLogic Server 7.0 SP2 environment, you must migrate them to SP2 before you can use them.

If you are migrating domains from WebLogic Server 7.0 to WebLogic Server 7.0 SP2, follow the instructions for migrating 7.0 domains to 7.0 SP1 domains in Migrating Domains Created Using the Configuration Wizard. If you have WebLogic Workshop domains, you must also follow the procedure in Migrating a WebLogic Workshop Domain from SP1 to SP2.

If you are migrating domains from WebLogic Server 7.0 SP1 to SP2, you must run the migration scripts as described in Step 1: Upgrade Product JAR Files. If you have WebLogic Workshop domains, you must also follow the procedure in Migrating a WebLogic Workshop Domain from SP1 to SP2.

Note: In addition to migrating domains to SP2, the migration scripts also upgrade the Sun SDK 1.3.1_03 to Sun SDK 1.3.1_06. If the Sun SDK is not used in your environment, modify your scripts appropriately.

Migrating a WebLogic Workshop Domain from SP1 to SP2

If you have a domain that you created with WebLogic Workshop 7.0 or 7.0 SP1, then you must revise the startWeblogic script for your Workshop domain as follows:

  1. Add:
    call%WL_HOME%\common\bin\commEnv.cmd

    You can add this line anywhere before the set JAVA_DEBUG statement. For new domains created with the Configuration Wizard using the WebLogic Workshop template, the startWeblogic script includes the call immediately following the lines that set the WL_HOME, BEAHOME, and JAVA_HOME variables. For example:

    set WL_HOME=c:\bea\weblogic700
    set BEAHOME=c:\bea
    set JAVA_HOME=c:\bea\jdk131_06
    CALL%WL_HOME%\common\bin\commEnv.cmd

  2. Replace:
    set JAVA_DEBUG=-hotspot

    with the following line:

    JAVA_DEBUG=%COMM_CLIENT_VM%

Updating WebLogic Server 7.0 to 7.0 Service Pack 2

If you installed the stand-alone WebLogic Server 7.0 and did not upgrade to the WebLogic Platform Edition you cannot use Smart Update to install WebLogic Server 7.0 Service Pack 1. Instead you can use a package upgrade installer that you can download from the BEA Customer Support Web site at http://support.bea.com. For instructions, see Installing Service Packs and Rolling Patches with a Downloadable Installer in Installation Guide.

To see which version of WebLogic Server you have installed, open BEA_HOME\logs\log.txt (BEA_HOME/logs/log.txt on UNIX) in a text editor and look at the last entry in the log file. Each line in the log file represents an installation event for the current BEA home—an installation or an uninstallation. If the log entry indicates that the version installed is WebLogic Platform Edition 7.0 SP0 or earlier, you cannot use Smart Update. If the log entry indicates that the version installed is WebLogic Platform Edition (7.0.0.1) or later, you can use Smart Update to install WebLogic Server Service Pack 2.

WebLogic Server and WebLogic Platform Edition use the same installation framework. Therefore, installation log entries use the term WebLogic Platform to indicate an installation of either WebLogic Server or WebLogic Platform Edition.

Performance Enhancements

WebLogic Server 7.0 SP2 introduces important performance-related enhancements:

New and Changed Security Documentation

A new manual, Securing WebLogic Resources is available for this release of WebLogic Server. In addition, Introduction to WebLogic Security, Managing WebLogic Security, and Programming WebLogic Security have been significantly updated.

Web Services

WebLogic Server 7.0 SP2 includes support for the following new Web services features:

Optimized JMS Topic Subscriber Message Selectors

For a certain class of applications, WebLogic JMS can optimize topic subscriber message selectors significantly by indexing them. These applications have messages that contain one or more unique identifiers and thousands of subscribers that filter based on these identifiers.

A typical example is an instant messaging application where each subscriber corresponds to a different user, and each message contains a list of one or more target users. See Indexing Topic Subscriber Message Selectors To Optimize Performance in Programming WebLogic JMS.

Extra EJB Compiler Options at the Server Level

You can now specify extra EJB Compiler options in the Administration Console at the server level— under Server -> Configuration—in addition to at the EJB module level—under EJB -> Configuration ->Advanced options.

Note: The EJB-level settings take precedence. If the EJB-level options are set to null on the EJBComponentMbean, WebLogic Server applies the value specified at the server level, on the ServerMBean.

New Features for Installing WebLogic Server as a Windows Service

The WebLogic Server utility that sets up WebLogic Servers to run as Windows services has been modified:

New Default Version for the Oracle Thin Driver

The default Oracle JDBC Thin driver has been changed to the 9.2.0 version. In releases of WebLogic Server 7.0 prior to the Service Pack 2 release, the 8.1.7 version of the Oracle Thin driver was the default version.

For more information about using different versions of the Oracle Thin driver, see Changing or Updating the Oracle Thin Driver in Programming WebLogic JDBC.

 


What's New in WebLogic Server 7.0 SP1

The following sections contain important notes for BEA WebLogic Server 7.0 SP1.

JMS

Service Pack 1 offers new JMS features.

Full Compliance with the JMS Specification 1.0.2b

WebLogic JMS is now fully compliant with Sun Microsystems' JMS Specification version 1.0.2b. As a result, message property names must now strictly conform to the message selector syntax specifications for Java identifiers, as defined in the javax.jms.Message Javadoc.

Synchronous Write Policy for JMS File Stores

In WebLogic Server 7.0 Service Pack 1, WebLogic JMS file stores guarantee up-to-the-message integrity by using synchronous writes by default. Disabling synchronous writes improves file store performance, often dramatically, but at the expense of possibly losing sent messages or generating duplicate received messages (even if the messages are transactional) in the event of an operating system crash or a hardware failure.

See Configuring a Synchronous Write Policy for JMS File Stores in the Administration Guide.

Servlets

Beginning with WebLogic Server 7.0 Service Pack 1, a servlet's initialization is invoked as the <init-as> user, specified in weblogic.xml. If not specified in weblogic.xml, then it is invoked as the <run-as> user, specified in web.xml If not specified here either, then it is invoked as the <anonymous> user.

As a result of this change, the <init-as> and <destroy-as> elements were added to the weblogic.xml deployment descriptor. For more information, see "weblogic.xml Deployment Descriptor Elements" in Developing WebLogic Server Web Applications.

Web Services

Service Pack 1 of WebLogic Web services includes support for implementing document-oriented Web service operations. As described in the WSDL 1.1 specification, document-oriented Web service operations are those in which the SOAP messages contain documents, as opposed to RPC-oriented Web services whose SOAP messages contain parameters and return values. For details, see RPC-Oriented or Document-Oriented Web Services.

Service Pack 1 of WebLogic Web Services also includes the following new Ant tasks:

In addition, the servicegen Ant task has the following new attributes used to assemble a JMS-implemented Web service:

For reference information about these Ant tasks, see Web Service Ant Tasks and Command-Line Utilities.

Note: The wsdl2Service Ant task is a preliminary implementation and has not been fully tested in this release.

WebLogic jDriver for Oracle 9.2.0

With the release of WebLogic Server 7.0 Service Pack 1, WebLogic jDriver for Oracle version 9.2.0 and Oracle Thin Driver version 9.2.0 are certified for use with WebLogic Server 7.0. You can use these drivers to connect to an Oracle 9.2.0 database and create database connections in a JDBC connection pool.

For more information, see the following related documents:

New Security-Related Element for EJBs

The 7.0 SP1 release introduces a new weblogic-ejb-jar.xml element: global-role. This element indicates that a particular security role is defined "globally" in a security realm. See Programming WebLogic Enterprise JavaBeans for details.

WebLogic Server 7.0 Platform Edition and WebLogic Server 7.0 Standalone

WebLogic Server 7.0 Platform Edition, released on June 28, 2002, incorporated two new features that are also included in WebLogic Server 7.0 SP1. If you downloaded WebLogic Server before that date you have the WebLogic Server 7.0 standalone version. WebLogic Server 7.0 Platform Edition differs from WebLogic Server 7.0 stand-alone as follows:

WebLogic Server 7.0 SP1 incorporates these features.

Updating WebLogic Server 7.0 to 7.0 Service Pack 1

If you installed the stand-alone WebLogic Server 7.0 and did not upgrade to the WebLogic Platform Edition, released June 28, 2002, you cannot use Smart Update to install WebLogic Server 7.0 Service Pack 1. Instead you can use a package upgrade installer that you can download from the BEA Customer Support Web site at http://support.bea.com. For instructions, see Installing Service Packs and Rolling Patches with a Downloadable Installer in Installation Guide.

To see which version of WebLogic Server you have installed, open BEA_HOME\logs\log.txt (BEA_HOME/logs/log.txt on UNIX) in a text editor and look at the last entry in the log file. Each line in the log file represents an installation event for the current BEA home—an installation or an uninstallation. If the log entry indicates that the version installed is WebLogic Platform Edition 7.0 SP0 or earlier, you cannot use Smart Update. If the log entry indicates that the version installed is WebLogic Platform Edition (7.0.0.1) or later, you can use Smart Update to install WebLogic Server Service Pack 1.

Note: WebLogic Server and WebLogic Platform Edition use the same installation framework. Therefore, installation log entries use the term WebLogic Platform to indicate an installation of either WebLogic Server or WebLogic Platform Edition.

Migrating Domains Created Using the Configuration Wizard

The Configuration Wizard (introduced in WebLogic Platform 7.0) allows you to create new domains quickly and easily. If you created domains using the Configuration Wizard in WebLogic Platform 7.0, you need to migrate those domains for use with WebLogic Platform 7.0 Service Pack 1.

For most domains, migration is a three-step process:

  1. Upgrade the product JAR files in the domain directory. A migration script is provided for this purpose. See instructions in Step 1: Upgrade Product JAR Files.

    Note: You can also revert a domain to its pre-migration state.

  2. Update the domain to support Service Pack 1 changes. Depending on the domain template used to generate the domain, you may need to add or modify existing scripts or files. See instructions in Step 2: Update Domain to Support Service Pack 1 Changes.

  3. If you installed WebLogic Platform 7.0 Service Pack 1 into a new directory, separate from the WebLogic Platform 7.0 installation, update the domain startup scripts and configuration files to reference the new BEA_HOME directory location. See instructions in Step 3: Update Startup Scripts and Configuration Files to Reference New BEA_HOME Directory Location (Non-Upgrades Only).

    Note: If you upgraded your existing WebLogic Platform 7.0 installation, you can skip this step.

You will need to repeat this process for each domain that you want to migrate.

Note: This section describes how to migrate domains specific to WebLogic Server. For information about migrating other WebLogic Platform domains, see "Migrating Domains Created Using the Configuration Wizard" in the WebLogic Platform 7.0 Service Pack 2 Release Notes at the following URL:

http://download.oracle.com/docs/cd/E13196_01/platform/docs70/relnotes/relnotes.html#migration

Step 1: Upgrade Product JAR Files

To upgrade product JAR files for a 7.0 domain that you generated using the Configuration Wizard to Service Pack 1, navigate to the BEA_HOME\weblogic700\server\bin directory and execute one of the following commands:

Windows: migrate.cmd domain mode
UNIX: migrate.sh domain mode

Note: You will be prompted to press any key to start processing.

The following table defines the command-line arguments.

Table 1-1 Command-line Arguments for Upgrading 7.0 Product JAR files to 7.0 SP1

Argument

Description

domain

Full pathname of the domain directory.

mode

Migration mode. The mode can be set to one of the following values:

  • upgrade: Upgrade the product JAR files in the domain directory, as required. The original product JAR files are saved as *.jar.orig. If the timestamp of an existing product JAR file is more recent than the timestamp on the corresponding SP1 installation product JAR file, the file is skipped. This is the default mode.

  • revert: Reverts a domain that was migrated earlier using the backup files (*.jar.orig) generated. If no *.jar.orig files exist, the command is ignored.


 

For example, the following command upgrades a domain called mydomain located in the default user projects directory (BEA_HOME\user_projects):

Windows: migrate.cmd c:\bea\user_projects\mydomain upgrade
UNIX: migrate.sh c:/bea/user_projects/mydomain upgrade

The following command reverts the changes made to mydomain during the migration:

Windows: migrate.cmd c:\bea\user_projects\mydomain revert
UNIX: migrate.sh c:/bea/user_projects/mydomain revert

Step 2: Update Domain to Support Service Pack 1 Changes

Depending on the domain template used to generate the domain, you may need to add or modify existing scripts or files to support WebLogic Platform 7.0 Service Pack 1 changes. Refer to the appropriate section below, based on the domain template used to generate the domain, for additional migration steps:

Note: Before adding or modifying any files, as described in the following sections, it is recommended that you backup the original files.

WebLogic Workshop Domain

For a domain that is based on the WebLogic Workshop template, perform the following steps:

  1. Modify the startWebLogic.cmd (Windows) or startWebLogic.sh (UNIX) command to reflect the appropriate PointBase version (183 versus 172) in the JAR filenames defined in the CLASSPATH. The files for both commands are located in the following directory, by default:
    BEA_HOME\user_projects\domain

    The following sample excerpt from the startWebLogic.cmd script (Windows) shows the required updates in bold:

    Before:

    set PB_CLASSPATH=
    %POINTBASEDIR%\eval\pointbase\lib\pbserver42ECF
    172.jar;
    %POINTBASEDIR%\eval\pointbase\lib\pbclient42ECF
    172.jar

    After:

    set PB_CLASSPATH=.\;
    %POINTBASEDIR%\eval\pointbase\lib\pbserver42ECF
    183.jar;
    %POINTBASEDIR%\eval\pointbase\lib\pbclient42ECF
    183.jar

  2. Copy the following files from the BEA_HOME\weblogic700\samples\workshop directory to the BEA_HOME\user_projects\domain directory of your WebLogic Workshop domain. Be careful not to overwrite any files that may have been created using one of these filenames.
    setWorkshopEnv.cmd
    setWorkshopEnv.sh
    startPointBaseConsole.cmd
    startPointBaseConsole.sh
    URLs.dat

    WLS Domain

For a domain that is based on the WLS Domain template, you do not need to add or modify existing scripts or files.

WLS Examples

For a domain that is based on the WLS Examples domain template, perform the following steps:

  1. Modify the CLASSPATH definition in the startExamplesServer.cmd (Windows) or startExamplesServer.sh (UNIX) command to:

    • Reflect the appropriate PointBase version (183 versus 172) in the JAR filenames.

    • Add the BEA_HOME\server\lib\webservices.jar file.

    The files for both commands are located in the following directory, by default:

    BEA_HOME\user_projects\domain

    The following sample excerpt from the startExamplesServer.cmd script (Windows) shows the required updates in bold:

    Before:

    set CLASSPATH=
    c:\bea\jdk131_03\lib\tools.jar;%POINTBASE_HOME%\lib\
    pbserver42ECF
    172.jar;%POINTBASE_HOME%\lib\
    pbclient42ECF
    172.jar;%CLIENT_CLASSES%;%SERVER_CLASSES%;
    %COMMON_CLASSES%;%CLIENT_CLASSES%\utils_common.jar

    After:

    set CLASSPATH=
    c:\bea\jdk131_03\lib\tools.jar;%POINTBASE_HOME%\lib\
    pbserver42ECF
    183.jar;%POINTBASE_HOME%\lib\
    pbclient42ECF
    183.jar;%CLIENT_CLASSES%;%SERVER_CLASSES%;
    %COMMON_CLASSES%;%CLIENT_CLASSES%\utils_com
    mon.jar;
    c:\bea\weblogic700\server\lib\webservices.jar

  2. Copy the Webservices_trader.ear file from the BEA_HOME\samples\server\config\examples\applications directory to the BEA_HOME\user_projects\WLSExampleDomain\applications directory of your Web applications. Be careful not to overwrite any files that you have customized.

    WLS Petstore

For a domain that is based on the WLS Petstore domain template, modify the startPetStore.cmd (Windows) or startPetStore.sh (UNIX) command to reflect the appropriate PointBase version (183 versus 172) in the JAR filenames defined in the CLASSPATH.

The files for both commands are located in the following directory, by default:

BEA_HOME\user_projects\domain

The following sample excerpt from the startPetStore.cmd script (Windows) shows the required updates in bold:

Before:

set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%POINTBASE_HOME%\lib\pbserver42ECF172.jar;%POINTBASE_HOME%\lib\pbclient42ECF172.jar;%SERVER_CLASSES%;%COMMON_CLASSES%

After:

set CLASSPATH=%JAVA_HOME%\lib\tools.jar;%POINTBASE_HOME%\lib\pbserver42ECF183.jar;%POINTBASE_HOME%\lib\pbclient42ECF183.jar;%SERVER_CLASSES%;%COMMON_CLASSES%

Step 3: Update Startup Scripts and Configuration Files to Reference New BEA_HOME Directory Location (Non-Upgrades Only)

Note: This step is only required if you installed WebLogic Platform 7.0 Service Pack 1 into a new directory that is separate from the WebLogic Platform 7.0 installation. If you upgraded your existing WebLogic Platform 7.0 installation, you can skip this step.

The domain startup scripts (such as, startWebLogic) and configuration files (such as config.xml) define the full pathnames to files within the BEA_HOME directory. You need to search for and update these full pathnames to reference the new BEA_HOME directory location. In addition, you must update any custom scripts, such as build scripts, that define full pathnames to the files within the BEA_HOME directory to reflect the new BEA_HOME location.

Many startup scripts set environment variables in your current shell, including variables that reference your BEA_HOME directory. After updating the BEA_HOME references in script files, you should open a new shell to ensure that the latest environment settings are used.

 


What's New in WebLogic Server 7.0

BEA WebLogic Server changed significantly in the 7.0 release. This section details major differences between WebLogic Server 7.0 and earlier versions. Later sections describe additional changes in service pack releases.

Web Services

New features provide additional flexibility, ensure interoperability with other key Web Services vendors, and allow J2EE programmers to easily expose J2EE components as Web Services. The programming model shields the user from the complexities of SOAP and WSDL while providing optional extensibility. The new features include:

For more information about WebLogic Web services, see Programming WebLogic Web Services.

Security Infrastructure

The completely redesigned WebLogic Security Service offers a modular design that exposes a set of fully implemented SSPIs (Security Service Provider Interfaces) for authentication, authorization, auditing, role mapping, credential mapping, and keystore (PKI) management. Modules from third-party security vendors can plug right into the WebLogic Server Framework, and third-party administration tools can be integrated into the Administration Console. A new role-based authorization module can be applied to all J2EE and non-J2EE resources, and an embedded security policy engine makes it easy to create prose-based rules for dynamically assigning roles and access privileges. See the WebLogic Security Documentation.

Developer Tools

WebLogic Builder prepares Java files for quick deployment to the application server. WebLogic Builder is a graphical tool for assembling a J2EE application module, creating and editing its deployment descriptors, and deploying it to WebLogic Server. To run the tool, start the server, set your environment in a shell and type: java weblogic.marathon.Main. For more information, see the WebLogic Builder Online Help.

EJBGen is an EJB generation tool that uses javadoc comments to generate, from a single bean source file, deployment descriptor files and the EJB home, local, and remote interfaces. For more information, see Programming WebLogic Enterprise JavaBeans.

The weblogic.Deployer utility replaces the earlier weblogic.deploy utility. Use weblogic.Deployer to deploy a new application; redeploy an application; redeploy part of an application; deactivate an application; undeploy an application; cancel a deployment task; or list all deployment tasks, all from a simple command line interface.

WebLogic Server 7.0.0.1 and later versions also include BEA WebLogic WorkshopTM, an integrated development framework that empowers all application developers — not just J2EE experts — to rapidly create, test, and deploy enterprise-class Web Service applications on the BEA WebLogic Enterprise PlatformTM. BEA WebLogic Workshop provides a unified development platform that enables developers to easily build and connect components, data, and application business logic, while insulating them from the complexities of J2EE. For the first time, application and enterprise developers can work together on the same platform in the same language, dramatically increasing productivity across IT organizations.

To get the details on these tools and more see our WebLogic Server Tools and Utilities Guide.

System Administration Enhancements

The following administrative improvements and new features were added in WebLogic Server 7.0:

Caching

WebLogic Server 6.0 introduced JSP Cache Tags to cache specific portions of JSPs in memory without unnecessary trips to the backend; WebLogic Server 7.0 CacheFilters enable you to configure caching easily for entire pages, URLs, and file types. Without requiring any code changes to the application, administrators can turn on caching and see immediate performance and scalability improvements.

Clustering

You can now set up clusters without multihoming your machine. In earlier releases, a cluster required a unique listen address for each server while each server listened on the same port. If you wanted to create a cluster on a single computer, you were required to set up a multihomed environment, with multiple IP addresses on a single computer. Now you can assign different listen port numbers to the different servers in the cluster, resulting in a clustered environment on a single machine with one listen address. For more information, see Using WebLogic Server Clusters.

EJB 2.0

New Enterprise JavaBeans (EJB) 2.0 features include dynamic query support for executing queries within application code; multiple DBMS table mapping with WebLogic Server container-managed persistence services; new EJB WebLogic QL support for subqueries, aggregate functions, queries that return result sets, case-insensitive searching and SELECT FOR UPDATE with NO WAIT statements; improved concurrency and caching; EJB link support; and support for bulk insert update. For more information about all new EJB features, see Programming WebLogic Enterprise JavaBeans.

Message-Driven Beans and Non-BEA JMS Providers

Beginning with WebLogic Server 7.0, applications with transactional MDBs can achieve exactly-once semantics with a non-BEA JMS provider for messages processed by an MDB. In addition, WebLogic Server will use XA to automatically enlist the non-BEA JMS provider in a transaction. For details, see "Configuring Message-Driven Beans for non-BEA JMS Providers" .

Directory Structure

BEA changed the directory structure and the location of applications built on WebLogic Server 7.0. This new directory structure provides added flexibility and promotes best practices for application development. See the BEA Home Directory section in the WebLogic Server Installation Guide for more information.

Configuration Wizard

Domain and cluster management are greatly simplified by a Configuration Wizard that lets you generate pre-configured domains in any location. A domain is an interrelated set of WebLogic Server resources that share configuration files and are managed as a unit that includes WebLogic Server instances, WebLogic Server clusters, and applications. Based on user queries, the Configuration Wizard generates a domain, server, and enterprise application with the appropriate components pre-configured and assets included. You can run the Domain Configuration Wizard during a custom installation and anytime thereafter. The Configuration Wizard is especially designed to make setting up clusters easy. The scripts for starting the Configuration Wizard are located in your WL_HOME\common\bin directory.

Installation

The following installation enhancements are new to this release of WebLogic Server. For more detailed information, see the Installation Guide.

Installation Options

When installing WebLogic Server 7.0, you can choose between typical and custom installation options. The typical installation includes the most common options for quickly installing WebLogic Server. With the custom installation, you can choose installation options and configure a domain during the installation.

Smart Updates

WebLogic Server 7.0 includes a new installer program that you can also use to find and install service packs and product updates.

J2EE Connectors

J2EE Connectors define a standard method of integrating WebLogic Server applications with existing applications. WebLogic Server 7.0 implements the finalized version of the Connectors 1.0 specification. This release also includes enhancements to connection and security management for JCA adapters.

The following J2EE Connector Architecture enhancements are new to this release of WebLogic Server. For more detailed information, see Programming the WebLogic J2EE Connectors .

JNDI Implementation

This release supports a referencable JNDI implementation. BEA has provided united testing to confirm that previous related problems have been resolved.

Secure Password Credential Storage

This release provides a standard method for resource adapter deployers to plug in their specified authorization/authentication mechanism through secure password credential storage. This WebLogic Server storage mechanism has replaced the Security Principal Mapping mechanism provided with the weblogic-ra.xml deployment descriptor within the resource adapter archive.

This new storage mechanism is used to map initiating principals (such as WebLogic Server username and password combinations) to resource principals (EIS user name and password combinations).

Connection Leak Detection

In the past release, the connection leak detection mechanism was based upon a timer that started when a connection was created and triggered when the connection exceeded its usage duration. WebLogic Server now provides new mechanisms for preventing this scenario, leveraging a garbage collector and providing an idle timer for tracking the usage of connection objects.

Dynamic Pool Modification

This release provides dynamic runtime changes to the various connection pool parameters that are configurable at runtime. When you make changes to these parameters using the Console Deployment Descriptor Editor, the changes take place immediately. You do not need to reboot WebLogic Server and redeploy the resource adapter.

Security Policy Processing of a ra.xml Specification

BEA WebLogic Server J2EE Connector Architecture provides a set of security permissions for execution of a resource adapter in a managed runtime environment. WebLogic Server also grants a resource adapter explicit permissions to access system resources.

jCOM

WebLogic jCOM is a software bridge that allows bi-directional access between Java and J2EE objects deployed in WebLogic Server, and Microsoft ActiveX components available within Microsoft Office family of products, VisualBasic and C++ objects, and other COM/DCOM-compliant environments.

WebLogic jCOM allows Microsoft COM clients to access objects in WebLogic Server as though they were COM components and applications within WebLogic Server to access COM components as though they were Java objects. In both cases, WebLogic jCOM makes the differences between the object types transparent: to a COM client, WebLogic Server objects appear to be COM objects and to a WebLogic Server application, COM components appear to be Java objects.

JDBC

The following are new or improved features of WebLogic JDBC.

Support for ARRAYs, STRUCTs, and REFs

WebLogic Server 7.0 includes support for ARRAYs, STRUCTs, and REFs, including the standard JDBC methods and some Oracle extensions. To use ARRAYs, STRUCTs, or REFs, you must use the Oracle Thin Driver. See Oracle Thin Driver Extensions in Programming WebLogic JDBC.

JDBC Connection Pool Administration MBean

WebLogic Server provides the JDBCConnectionPool administration MBean as part of the WebLogic Server management architecture (JMX). You can use the JDBCConnectionPool MBean to dynamically create and configure a connection pool from within a Java application. See Creating a Connection Pool Dynamically in Programming WebLogic JDBC for more information.

Third-Party JDBC Drivers Shipped with WebLogic Server

WebLogic Server includes several versions of the Oracle Thin Driver and the Sybase jConnect JDBC driver stored in different folders in the directory structure. You can select which version of the JDBC driver you want to use. You can also easily update a driver with a version from the DBMS vendor. See Overview of Third-Party JDBC Drivers in Programming WebLogic JDBC for more information.

Oracle 9i Support

WebLogic Server now supports Oracle 9i. To connect to an Oracle 9i database, you must use a JDBC driver that supports Oracle 9i, such as the WebLogic jDriver for Oracle or the Oracle Thin Driver version 9.0.1 or later. For more information, see Installing and Using WebLogic jDriver for Oracle and Programming WebLogic JDBC.

JMS

The following are new features of WebLogic JMS.

Enhanced Availability

WebLogic JMS takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments. This allows WebLogic JMS to respond properly to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure.

For more information, see "Managing JMS" in Programming WebLogic JMS .

Distributed Destinations within WebLogic Clusters

The highly available implementation of WebLogic JMS offers a level of service continuity in the event of a single server failure within a cluster by enabling you to configure multiple physical destinations as members of a single distributed destination set. Specifically, an administrator can configure multiple instances of a given destination (queue or topic) within a cluster. If one instance within the cluster fails, then other instances of the same distributed destination will be able to provide service to JMS producers and consumers.

For more information, see "Developing a WebLogic JMS Application" in Programming WebLogic JMS and "Managing JMS" in the Administration Guide .

Flow Control

Using the Flow Control feature, you can enable a JMS server or destination to slow down message producers when it determines that it is becoming overloaded. Specifically, when a JMS server or destination exceeds its specified bytes or messages thresholds, it instructs producers to limit their message flow.

For more information, see "Managing JMS" in the Administration Guide .

WebLogic Messaging Bridge

A messaging bridge is responsible for transferring messages between two messaging providers. The WebLogic Messaging Bridge feature allows you to configure a store-and-forward mechanism between any two messaging products—including separate implementations of WebLogic JMS.

For more information, see "Configuring a Messaging Bridge" in the Administration Guide.

Message Paging

The Message Paging feature can free up valuable virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold. From a performance perspective, this feature can greatly benefit WebLogic Server implementations with the large message spaces that are required by today's enterprise applications.

For more information, see "Managing JMS" in the Administration Guide.

Server Affinity With Destination Lookup

The createTopic() and createQueue() methods now allow a "JMS_Server_Name./Destination_Name" syntax to indicate server affinity when you are looking up destinations. When a destination is locally deployed in the same JVM as the connection factory, the connection factory only returns names matching local destinations. If the name is not on the local JVM an exception is thrown, even though the same name might be deployed on a different JVM.

An application can use this convention to avoid hard-coding the server name when using the createTopic and createQueue methods so that the code can be re-used as is on other JMS servers. For more information, see Developing a WebLogic JMS Application in Programming WebLogic JMS.

BEA Jolt Client 8.0.1

BEA Jolt Client 8.0.1 is a Java-based client API that manages requests to Tuxedo services via a Jolt Service Listener (JSL) running on the Tuxedo server. The Jolt API is embedded within the WebLogic API and is accessible from a servlet or any other BEA WebLogic application.

The Jolt Java Client 8.0.1 is available from the BEA Product Download Center. Follow the link to BEA WebLogic Server 7.0 and select the Jolt Java Client 8.0.1 from the Modules for WebLogic Server list. A Jolt license is required.

Java Transaction API (JTA)

The following Java Transaction API enhancement is new to this release of WebLogic Server, For more detailed information see, Programming WebLogic JTA.

Transaction Recovery Service Migration

In WebLogic Server 7.0, you can migrate the Transaction Recovery Service from one server in a cluster to another server in the same cluster, which provides highly-available transaction recovery. The Transaction Recovery Service completes incomplete transactions for a failed server. See Transaction Recovery After a Server Fails in the WebLogic Server Administration Guide.

Network Resources

WebLogic Server 7.0 introduces two new types of configurable network resources that you can administer using either the Administration Console or WebLogic Server MBeans. These resources are network channels and Network Access Points (NAPs).

A network channel defines the basic attributes of a network connection to WebLogic Server. You configure channels as distinct entities in the Administration Console, and then add one or more channels to servers in a domain. Using a single channel with multiple servers can simplify network configuration for a WebLogic Server domain, because changing the channel configuration automatically changes the connection attributes of all servers that use the channel. You can also create and assign multiple channels to a single server. Using multiple channels helps you segment network traffic by protocol, listen ports, or any other channel configuration property. For example, you can use two channels with a single server to tailor the default connection properties for secure vs. non-secure traffic. For more information, see Configuring Network Resources.

A Network Access Point (NAP) is a configurable resource that represents the actual port numbers and, optionally, the specific IP address that a network channel uses. Although network channels alone can help you manage shared connection properties in a domain, channels are more commonly used in conjunction with NAPs to segment network traffic among multiple NICs and port numbers. NAPs also override certain channel attributes to customize a WebLogic Server's network configuration. For more information, see Configuring Network Resources.

RMI-IIOP

The WebLogic implementation of RMI-IIOP now includes the following features, as well as numerous performance enhancements:

Updated Security Configuration Procedure for Web Applications and EJBs

The procedure for protecting Web applications and EJBs has been improved in this release of WebLogic Server. For a complete description, see Securing WebLogic Resources.

WebLogic Tuxedo Connector

WebLogic Tuxedo Connector now includes the following features:

WebLogic XML

WebLogic Server 7.0 includes the following new XML features:

For more information about these new features, see Programming WebLogic XML.

Documentation and Examples

The following items include enhancements to the documentation and the samples provided with WebLogic Server 7.0.

Documentation

E-docs is the source for WebLogic Server information. The documentation covers all the newest features and changes in WebLogic Server 7.0. The Administration Console Help is greatly improved and is available from E-docs. Also, the following new guides have been added:

There have been many improvements made to the examples featured in WebLogic Server 7.0. Changes include the following:

Several new examples demonstrate the following features:

The Pet Store sample application that is provided with WebLogic Server 7.0 has been upgraded to version 1.3. The Pet Store application is available from the Start menu and the source code is located in the SAMPLES_HOME\server\src\petstore directory, where SAMPLES_HOME is the location of all examples for the WebLogic Platform. By default, this location is c:\bea\weblogic700\samples.

WebLogic Server Tour

The WebLogic Server Tour is an overview of WebLogic Server that uses the Pet Store application to demonstrate features. The Tour is available from the Start menu.

 


Platform Support

See the Platforms Support Page for the most accurate and current information regarding platform support.

 


Versions Compatibility for Standards and Libraries

The table below lists versions of standards and libraries included with or compatible with WebLogic Server 7.0.

Table 1-2 Standards and Libraries Compatible with WebLogic Server 7.0

Standard or Library

Version

org.w3c.dom interfaces


org.xml.sax interfaces


antlr

2.7.1

EJB

2.0 and 1.1

HTTP

1.1

JAAS

.0 Full

Java RMI

1.0

JavaMail

1.1

JAXP

1.1

JAX-RPC

1.0

JCA

1.0

JDBC

2.0.x

JMS

1.0.2

JMX

1.0

JMX

1.0

JNDI

1.2

JSP

1.2 and 1.1

JTA

1.0.1

LDAP

2

Oracle

  • 8.1.7

  • 9.0.1

  • 9.2.0

OTS/JTA

1.2/1.0.1

RMI/IIOP

1.0

Servlet

2.3 and 2.2

SSL

3

X.509

3

Xerxes DOM and SAX

  • DOM parser: Level 2.0 Core

  • SAX parser: Version 2.0

XML

org.apache.xalan

Any version compatible with the version of Xerces XML parser.

XML parsers

org.apache.xerces

Built-in version: 1.4.4

Compatible with WebLogic Server 7.0.0.1 or previous:

  • 1.2.2

  • 1.2.3

  • 1.3.0

  • 1.3.1

  • 1.4.0

  • 2.0.0

  • 2.0.1

Compatible with WebLogic Server 7.0 SP1 or later:

  • Any version of Xerces

 


Java Development Kit

A JDK provides a Java runtime environment (the Java Virtual Machine or JVM) and tools for compiling and debugging your Java applications. Your installation of WebLogic Server 7.0 includes the 1.3.1_02 JDK from Sun Microsystems.

 


WebLogic Javadoc

BEA uses the Javadoc tool to generate documentation for externally supported APIs. Javadoc is a tool from Sun used to document API of classes that have been declared within the public scope. A class declared within the public scope is visible to other classes outside of its own package. BEA uses a custom version of Javadoc that has been enhanced to distinguish between externally supported public classes and public classes that are intended for internal use only. However, Javadoc may generate indirect references to internal classes or methods in usage pages, inheritance trees, or in other supplemental lists. Such indirect references do not imply support for internal methods or classes. BEA supports only those APIs that are fully documented on the main Javadoc pages for the classes to which they belong. In other words, when you select a package in the upper left-hand frame, all externally supported classes within that package will appear in the lower left-hand frame.

 


Creating Your Own MBeans

WebLogic Server provides hundreds of MBeans to configure and monitor WebLogic services such as the Security Service and JMS and deployable J2EE modules such as EJBs and Web applications. If you want to use additional MBeans to configure your applications or services, you can create your own MBeans.

If you want to create MBeans for a security provider, use the MBean-generation tools provided by the WebLogic Security Service. These tools are supported only for generating security-provider MBeans. For information on security providers, refer to Developing Security Providers for WebLogic Server.

If you want to create MBeans for any other managed resource on WebLogic Server, refer to the JMX specification (which you can download from http://java.sun.com/products/JavaManagement). MBeans that you create and register on a WebLogic Server instance can take advantage of the full set of JMX features as defined by the JMX specification. For more information about the WebLogic Server implementation of JMX, refer to Programming WebLogic Management Services with JMX.

 


Other Available Resources

Here are some pointers to useful information related to WebLogic Server 7.0. The hyperlinks require Internet access.

Fast Track Procedures

High-level procedures to help you quickly deploy an HTML file, JSPs, and servlets, are available at http://download.oracle.com/docs/cd/E13222_01/wls/docs70/quickstart/quick_start.html.

Pet Store 1.3

The Pet Store sample application demonstrates WebLogic Server features. It is available from the Start menu in the directory where you installed WebLogic Server 7.0.

Examples

Code examples, if installed, are located in the SAMPLES_HOME\server\src\examples directory of your WebLogic Server installation, where SAMPLES_HOME is the location of all examples for the WebLogic Platform. By default, this location is c:\bea\weblogic700\samples. Examples are also available from the Start menu for Windows users.

Introduction

For an overview of WebLogic Server features and the J2EE application architecture, see Introduction to WebLogic Server.

Additional Documentation

The full documentation set for BEA WebLogic Server, including administration, programming, and reference guides, is provided on the BEA WebLogic Server Online Documentation CD-ROM and on the BEA Web site at http://www.oracle.com/technology/documentation/index.html.

Newsgroups

BEA WebLogic Server newsgroups provide community support for BEA products. Information about BEA-related newsgroups can be found at http://newsgroups.bea.com/ and news://newsgroups.bea.com.

Dev2Dev Online

The BEA site Dev2Dev Online provides resources to make your e-commerce development easier and faster. To reach Dev2Dev online, go to http://developer.bea.com/.

 

Back to Top Previous Next