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

WebLogic Server 6.1 Features and Changes

The following sections describe changes and features in WebLogic Server 6.1.

The current release is WebLogic Server 6.1 Service Pack 6. Each Service Pack contains the changes and corrections introduced in prior Service Packs.

The following sections highlight the key changes in each WebLogic Server 6.1 Service Pack.

- WebLogic Server 6.1 Service Pack 7

- WebLogic Server 6.1 Service Pack 6

- WebLogic Server 6.1 Service Pack 5

- WebLogic Server 6.1 Service Pack 4

- WebLogic Server 6.1 Service Pack 3

- WebLogic Server 6.1 Service Pack 2

- WebLogic Server 6.1 Service Pack 1

- WebLogic Server 6.1 (G.A. Release)

For information about current known problems in WebLogic Server 6.1, see Notes and Problems.

WebLogic Server 6.1 Service Pack 7

These sections describe key changes in WebLogic Server 6.1 SP07.

- WebLogic Server 6.1 Service Pack 7 Solutions

- Oracle 10g Thin Driver Bundled with WebLogic Server

Oracle 10g Thin Driver Bundled with WebLogic Server

In WebLogic Server 6.1 Service Pack 7, the Oracle 10g Thin driver is installed with WebLogic Server in the WL_HOME\lib\oracle\10g folder. BEA provides the 10g driver so that you can optionally use it with WebLogic Server. However, the Oracle 9.2.0 Thin driver remains the default version of the driver. To use the Oracle10g Thin driver, you must add the driver classes to your CLASSPATH in front of weblogic.jar. See "Using the Oracle 10g Thin Driver" in Programming WebLogic JDBC for more information.

Note: Oracle removed some methods and classes from the 10g Thin driver that were in previous versions of the driver. If you use any of the extension methods that were removed, you will see errors in your application.

WebLogic Server 6.1 Service Pack 6

These sections describe bug fixes and key changes in WebLogic Server 6.1 SP06.

- WebLogic Server 6.1 Service Pack 6 Solutions

- Changes in EJB

- Changes in System Administration

Changes in EJB

A field optimization was implemented for EJB 1.1 CMP beans, so that fields that are updated but whose values are not changed are not written to back to the database. The optimization applies to primitive and immutable fields only.

Changes in System Administration

You must provide user credentials for any weblogic.Admin command that connects to a WebLogic Server instance. A new command, STOREUSERCONFIG, encrypts and stores user credentials, so that you do not have to pass unencrypted credentials on the command line or in scripts. For more information, see STOREUSERCONFIG in WebLogic Server Administration Guide.

WebLogic Server 6.1 Service Pack 5

These sections describe bug fixes and key changes in WebLogic Server 6.1 SP05.

- WebLogic Server 6.1 Service Pack 5 Solutions

WebLogic Server 6.1 Service Pack 4

These sections describe bug fixes and key changes in WebLogic Server 6.1 SP04:

- WebLogic Server 6.1 Service Pack 4 Solutions

- Changes in System Administration

- Changes in JDBC.

Changes in System Administration

This section lists key system administration changes in WebLogic Server 6.1 SP04.

Change in Behavior of -delay Argument for beasvc.exe

The behavior and usage of the -delay argument for beasvc.exe, the WebLogic Server Windows service program, is changed in WebLogic Server 6.1 SP04.

Previously, the -delay argument was applied when invoking beasvc.exe for Managed Server. When the Windows Service Control Manager (SCM) started a Managed Server as a service, it waited for the period (in milliseconds) specified with the -delay argument, set the service status to STARTED, and started the service.

In WebLogic Server 6.1 SP04, the -delay argument is applied at the Administration Server level, rather than for each Managed Server. Use the -delay argument when invoking beasvc.exe for the Administration Server for the domain. The argument affects all services that depend on the Administration Servers, including Managed Servers in the domain.

There are also changes in the effect that -delay has on service status and startup. In WebLogic Server 6.1 SP04, the Windows Service Control Manager (SCM) starts the Managed Server immediately, sets the service status to SERVER_START_PENDING, and after the specified delay has elapsed, sets the service status to STARTED.

New Parameter for Forced Application Update

A new startup option for Administration Servers, -Dweblogic.management.forceApplicationCopy, forces Managed Servers to obtain the latest version of deployed applications at startup. The effect of the startup option is described in Forcing Application Update at Startup. Default Application Update Process describes how Managed Servers obtain updates when -Dweblogic.management.forceApplicationCopy is false, as it is by default.

Forcing Application Update at Startup

The parameter -Dweblogic.management.forceApplicationCopy can be specified as a startup option for an Administration Server, either on the command line or in a startup script. If an Administration Server is started with -Dweblogic.management.forceApplicationCopy set to true, when a Managed Server in the domain starts up, the applications deployed to that Managed Server are copied from the Administration Server to the Managed Server.

Default Application Update Process

If an Administration Server is not started with -Dweblogic.management.forceApplicationCopy set to true, an application is only copied to a Managed Server at startup if both these conditions are true:

- the application has been modified and redeployed

- the Managed Server does not have the latest version of the application.

The Administration Server maintains a StagedTargets list that specifies which Managed Servers in a domain have the latest version of an application. At startup, a Managed Server queries its Administration Server to determine if it (the Managed Server) has the most recent version of the application. If an updated version of the application is available, it is copied to the Managed Server, and the Administration Server adds that Managed Server to the StagedTargets list.

When an Administration Server goes down, all Managed Servers are removed from the StagedTargets. When the Administration Server is rebooted, each Managed Server in the domain copies its deployed applications from the Administration Server. This assures that, in the event that an application has been updated while the Administration Server was down, all Managed Servers have the same version of the application.

Setting Default Encoding for JVM

Customers running WLS 6.1 SP04 and Sun JVM 1.3.1_06 attempted and failed to set the default encoding for the VM using the -Dfile.encoding attribute.

Since file.encoding is a read-only property this property cannot be changed, either on the command line or via the methods in the java.lang.System class.

Please see <http://developer.java.sun.com/developer/bugParade/bugs/4163515.html> and the related bugs for more details.

The preferred way to change the default encoding used by the VM and the runtime system is to change the locale of the underlying platform before starting your Java program.

Changes in JDBC

With the release of WebLogic Server 6.1 SP04, BEA certified the Oracle 9.2.0 Thin Driver for use with WebLogic Server. The software distribution for WebLogic Server 6.1 SP04 includes the following new JDBC drivers:

- WebLogic jDriver for Oracle 9.2.0, in addition to versions for Oracle 8.1.7 and 9.0.1.

- Oracle 9.2.0 Thin Driver, which replaces the 8.1.7 version that shipped with previous releases of WebLogic Server 6.1.

For more information about using WebLogic jDriver for Oracle, see Installing and Using WebLogic jDriver for Oracle. For more information about using the Oracle Thin Driver with WebLogic Server, see Using Third-Party Drivers with WebLogic Server.

In the Oracle Thin Driver version 9.2.0, Oracle removed some extension methods that were previously available in the driver. These methods are no longer supported and are not included in WebLogic Server 6.1 SP04:

Class:

weblogic.jdbc.oracle.OracleConnection

Method:

isCompatibleTo816()

Class:

weblogic.jdbc.oracle.OracleStatement

Method:

getWaitOption()
setWaitOption(int i)
setAutoRollback(int i)
getAutoRollback()

Class:

weblogic.jdbc.oracle.OracleResultSet

Method:

getCURSOR(String s)

WebLogic Server 6.1 Service Pack 3

These sections describe bug fixes and key changes in WebLogic Server 6.1 SP03:

- WebLogic Server 6.1 Service Pack 3 Solutions

- Changes in System Administration

- Changes in WebLogic jDriver Support

- Oracle 9.0.1 Thin Driver Certification

- Changes in JMS

Changes in System Administration

This section lists key system administration changes in WebLogic Server 6.1 SP03.

Strict Enforcement of ACLs

In WebLogic Server 6.1 SP03, an error in the implementation of ACLs for JDBC was fixed, which makes ACLs very strict. If you define an ACL for connection pools, access is restricted to exactly what is defined in the ACL. For more information, see Permissions at ../jdbc/programming.html#programming006.

Changes in WebLogic jDriver Support

The following list details recent changes to supported versions of Oracle used with WebLogic jDriver for Oracle:

- As of the release of WebLogic Server 6.1 SP03, BEA no longer supports WebLogic jDriver for Oracle with Oracle 8.1.6. If you are using WebLogic jDriver for Oracle to connect to an Oracle 8.1.6 database, you must upgrade to Oracle version 8.1.7 or 9.0.1, which includes the following steps on the machines on which WebLogic Server is running:

  - Upgrade the Oracle client installation to the 8.1.7 or 9.0.1 version.

  - Update the ORACLE_HOME environment variable to point to the updated version of the Oracle client.

  - Modify your PATH (on Windows, varies on UNIX) to include the path to the new Oracle client and to the appropriate version of the WebLogic jDriver for Oracle.

    For more information, see Setting Up the Environment for Using WebLogic jDriver for Oracle in Installing and Using WebLogic jDriver for Oracle.

Oracle 9.0.1 Thin Driver Certification

For the release of WebLogic Server 6.1 SP03, BEA certified the Oracle 9.0.1 Thin Driver for use with WebLogic Server. For more information about using the Oracle Thin Driver with WebLogic Server, see Using Third-Party Drivers with WebLogic Server.

Changes in JMS

WebLogic Server 6.1 SP03 includes the WebLogic Messaging Bridge.

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

For more information, see Using the WebLogic Messaging Bridge in the Administration Guide.

WebLogic Server 6.1 SP03 includes a new JMS message paging feature.

The WebLogic JMS 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.

Two metrics are used to determine when to start and stop paging: bytes paging and messages paging. Each metric is the basis of a single paging mode, which you can enable and disable individually, or use simultaneously, on JMS servers and/or destinations (topics and queues).

Paging is configured through the Administration Console. Using the paging attributes on the JMS Server node, you can specify a paging store for the server, enable bytes and/or messages paging, and configure the bytes/messages high and low thresholds to start and stop paging. Similarly, using the paging attributes on the Destinations node, you can configure bytes/messages paging for all topics and queues configured for the JMS server. The destinations use the paging store that is configured for the JMS server. Also, if you use JMS templates to configure multiple destinations, you can use the paging attributes on the Templates node to quickly configure message paging on all your destinations.

For detailed instructions on configuring message paging, see the section called "Tuning JMS" in the WebLogic Server Administration Guide.

WebLogic-Tuxedo Interoperability

WebLogic Server 6.1 SP3 interoperates with C++ clients using the Tuxedo 8.0 C++ Client ORB. Tuxedo release 8.0 RP 56 and above is required. WebLogic Server users should contact their BEA Service Representative for information on how to obtain the Tuxedo C++ Client ORB. For more information on how WebLogic Server interoperates with a Tuxedo C++ Client ORB, see RMI-IIOP with Tuxedo and Tuxedo Clients.

WebLogic Server 6.1 Service Pack 2

These sections describe bug fixes and key changes in WebLogic Server 6.1 SP02:

- WebLogic Server 6.1 Service Pack 2 Solutions

- Compatibility Issues

- Certifications

- Changes to Proxy Servlets

- New Security Classes

- Servlet and JSP Encoding Changes

- WebLogic 6.1 SP02 and 5.1 Interoperability

Compatibility Issues

This section describes compatibility issues in WebLogic Server 6.1 SP02.

Start Script Switch for WebLogic Server 6.1 SP02 Clients

By default, a WebLogic Server 6.1 SP02 client does not interoperate with a WebLogic Server 6.1 GA or 6.1 Service Pack 1 server. This is true both for a 6.1 SP2 client and a 6.1 SP2 server acting as a client to a 6.1 GA or 6.1 SP1 server.

To allow an SP2 client to talk to a 6.1 GA or 6.1 SP1 server, add the following switch to the WebLogic Server 6.1 SP02 start script:

-Dweblogic.61compat=true

SAX Parser and Encoding Error Detection

WebLogic Server's built-in SAX parser now correctly parses deployment descriptor files that are written using any character set.

Prior to this fix, WebLogic Server would have failed to detect encoding problems in your .xml files for English-only applications. Consequently, English-only applications that contained encoding problems and ran without fail in the past may now fail with this SP02 fix; WebLogic Server will report an encoding-not-supported error.

If WebLogic Server reports this error, check the specified .xml file for the correct encoding name and syntax.

Certifications

- WebLogic Server 6.1 SP02 is certified with Sun's J2SE 1.3.1_01.

- WebLogic Server 6.1 SP02 is certified with HP JVM 1.3.1_01. For information on the patches required by HP JVM 1.3.1_01, see the following website:

  http://www.hp.com/products1/unix/java/infolibrary/patches.html

- With the release of WebLogic Server 6.1 SP02, BEA supports WebLogic jDriver for Oracle for use with Oracle 9i. You can now use the JDBC driver to connect to an Oracle 9i database. For more information about WebLogic jDriver for Oracle, see Installing and Using WebLogic jDriver for Oracle.

For current information regarding platform support, see the Supported Configurations at

Changes to Proxy Servlets

WebLogic Server 6.1 SP02 includes new versions of the HttpClusterServlet and the HttpProxyServlet that support the HTTP 1.1 protocol. In addition, these servlets now use the same configuration parameters as the Apache, Netscape, and Microsoft IIS plug-ins.

For more information see the following documents:

- Proxying Requests to Another HTTP Server.

- Proxying Requests to a WebLogic Cluster.

- Parameters for Web Server Plug-ins.

New Security Classes

WebLogic Server 6.1 SP02 includes two new classes related to security:

- weblogic.security.SSL.TrustManager allows you to override validation errors in a peer's digital certificate and continue the SSL handshake. You can also use the class to discontinue an SSL handshake by performing additional validation on a server's digital certificate chain. For more information, see the section called "Using a Trust Manager" in "Programming with the WebLogic Security SPI".

- SSLContext is used to implement a secure socket protocol that holds information such as Host Name Verifier and Trust Manager for a given set of SSL connections. For more information, see the section called "Using an SSL Context" in "Programming with the WebLogic Security SPI".

In addition, SP02 adds parameters for SSL session caching that eliminate the need for the connection to go through the SSL handshake again. For more information, see the section called "Modifying Parameters for SSL Caching" in "Managing Security".

Servlet and JSP Encoding Changes

As of WebLogic Server 6.1 SP02, the default encoding used for servlets and JSPs has been changed to ISO8859_1. Previously the default encoding used was the JVM default. This change is in accordance with the latest servlet specification. Servlet Specification 2.3 SRV 4.9 states that the default encoding should be ISO8859_1.

BEA recommends you explicitly set the encoding of the request and response objects in order to avoid any encoding problems. For further details on how to set encoding, see http://edocs.beasys.co.jp/e-docs/wls61/jconfig/wls61jconfig.html.

WebLogic 6.1 SP02 and 5.1 Interoperability

As of WebLogic Server 6.1 SP02, it is possible to bi-directionally interoperate with WebLogic 5.1 Servers. This allows a WebLogic 6.1 Server to remotely invoke EJBs or RMI objects hosted on a WebLogic 5.1 Server. It also allows the reverse-a WebLogic 5.1 Server can remotely invoke EJBs or RMI objects hosted on a WebLogic 6.1 Server. For further details, see the Interoperability Guide.

WebLogic Server 6.1 Service Pack 1

For information on problems solved in WebLogic Server 6.1 SP01, see WebLogic Server 6.1 Service Pack 1 Solutions.

WebLogic Server 6.1 (G.A. Release)

These sections describe WebLogic Server 6.1 features, provides certification and standards support information, and highlights key known issues in the General Availability (G.A.) release.

- Notes for WebLogic APIs

- Deprecated Features and APIs

- Documentation and Examples

- J2EE and Standards Topics

- "Certifications"

Notes for WebLogic APIs

- Applets

- Beanshell Code

- Clustering

- Deployment in WebLogic Server 6.1

- Enterprise Java Beans (EJBs)

- Hypertext Transfer Protocol (HTTP) 1.1

- J2EE Connector

- Java Database Connectivity (JDBC)

- JavaMail

- Java Transaction API (JTA)

- JMS

- JSP

- Security

- Servlets and Web Applications

- SNMP

- System Administration

- WebLogic Tuxedo Connector

- XML

- Web Services

Applets

A problem with the tools.jar shipped with the JDK prevents Applets from being served to the client correctly. If tools.jar is located in your server CLASSPATH, you must ensure that weblogic.jar appears in the server CLASSPATH before tools.jar.

Beanshell Code

WebLogic Server uses an open source product called Beanshell. The initial developer of the original Beanshell code is Pat Niemeyer. Portions created by Pat Niemeyer are Copyright (C) 2000. All Rights Reserved. Beanshell is available under the Sun Public License and the GNU Lesser General Public License. The source code to Beanshell can be found at http://www.beanshell.org.

Clustering

Clusters of WebLogic Servers do not require a shared network drive. Both the WebLogic Server installations and your applications can now reside on local file systems.

Clusters, DNS, and Multihoming on NT

Be aware of naming issues when using multihoming features on Windows NT in a cluster. For example, there may be naming conflicts if a cluster is running on a multihomed Windows NT machine and one of the servers in the cluster is bound to the same DNS name as the machine name. Attempts to contact that server using the DNS name in a URL may result in Windows NT converting that DNS name to any of the IP addresses of the multihomed Windows NT machine. In this case, the request may go to the wrong address. Avoid having DNS names that match your machine name.

Deployment in WebLogic Server 6.1

In WebLogic Server 6.1, updating an application on any single server instance to which it is targeted causes it to be updated on all servers to which is targeted. For instance, if an application is targeted to a cluster, and you update it on one of the clustered servers instances, the application will be updated on all members of cluster. Similarly, if the application is targeted to a cluster and to a standalone server instance, updating it on the standalone server instance will result in its update on the cluster, and vice versa.

If you want to be able to update an application or component selectively on a subset of the server instances to which it is targeted, deploy unique instances to of the application to different targets.

New Deployment Tutorial Available

WebLogic Server 6.1 includes a new deployment tutorial, called "Deploying an Exploded J2EE Application". It is available on the WebLogic Server Samples and Tutorials page.

Enterprise Java Beans (EJBs)

WebLogic Server 6.1 includes many enhancements to WebLogic EJBs. For more information, see Programming WebLogic Enterprise JavaBeans.

EJB 1.1 and 2.0 Compliance

WebLogic Server 6.1 is compliant with the JavaSoft EJB 1.1 Specification. WebLogic also contains an optional implementation of the preliminary EJB 2.0 specification. The WebLogic Server EJB documentation describes key features of the EJB 2.0 Specification that you need to understand in order to use WebLogic Server.

New EJB features in this release include:

- Non-transactional entity bean caching

- Automated Generated Primary Key Support

- Automatic table creation

- Oracle SELECT HINTS

- EJB Deployment Descriptor Editor

- EJB Client.jar support

- BLOB and CLOB support

- Cascade deletion support

- Local Interface support

- Flushing the CMP cache support

- Tuned CMP 1.1 support

EJB Pass By Value J2EE incompatibility

Many of the WebLogic Server EJB deployment properties have default values that are optimized for performance. In some cases, these default values are not compliant with the EJB specification. Should you wish to make WebLogic Server compliant with the EJB specification, you must set the following properties:

In weblogic-ejb-jar.xml set "enable call by reference" to False.

In weblogic-cmp-jar.xml, set "include-updates" to True

In weblogic-cmp-jar.xml, set "check exists on method" to True.

Hypertext Transfer Protocol (HTTP) 1.1

The following sections refer to HTTP features supported with WebLogic Server 6.1.

Web Server

WebLogic Server 6.1 is a functional Web server that can handle high-volume Web sites, serving static HTML (text) files as well as servlets and JavaServer Pages (JSP). WebLogic Server 6.1 can also fully integrate with hardware- and software-based Web load-balancing solutions. WebLogic Server 6.1 supports the HTTP 1.1 standard.

Each WebLogic Server 6.1 hosts a default Web server and any number of additional Web servers that you define. Each of these additional Web servers is configured to respond to a different DNS name, in a process called Virtual Hosting.

You configure the attributes for Web servers using the new WebLogic Server Administration Console.

For more information, see Programming WebLogic HTTP Servlets.

HTTP Plug-ins for Apache, Netscape, and IIS

WebLogic Server 6.1 automatically implements keep-alive connections between the plug-ins and WebLogic Server. WebLogic Server 6.1 also supports SSL when using the HTTP plug-ins.

The Apache plug-in is now available for Apache 2.0 (non-SSL only). The Apache 2.0 version also supports HTTP 1.1 keep-alive connections.

For more information on SSL and each of the plug-ins, see the WebLogic Server Administration Guide.

HTTP Session Persistence

A new option is available for persisting HTTP sessions using cookies. For more information, see "Configuring Session Persistence".

HTML Pages and Netscape

If you already have a Netscape browser running when you start WebLogic Server, some HTML pages will not display. For example, if you select the About WebLogic Server page from the Start menu, and you have Netscape running and do not have Microsoft Internet Explorer, the screen may flash but the page will not display.

J2EE Connector

BEA WebLogic Server continues to build upon the implementation of the Sun Microsystems J2EE Platform Specification, Version 1.3 by supporting the J2EE Connector architecture. The BEA WebLogic J2EE Connector architecture enables you to connect existing legacy applications to the J2EE platform. The goal is to leverage the strengths of the J2EE platform—including component models, transaction, and security infrastructures—to address the challenges of integrating existing legacy applications.

The connector architecture defines a common interface between application servers and legacy applications, implemented in application specific resource adapters that plug in to application servers. The result is simplified enterprise application integration, using a scalable, standard architecture that leverages the benefits of the J2EE platform.

For more information, see Programming the WebLogic J2EE Connector Architecture

Java Database Connectivity (JDBC)

The following items are new or improved JDBC features.

MultiPools

JDBC MultiPools create a list of connection pools to be used by a single instance of WebLogic Server. A configurable algorithm determines which connection is returned. MultiPools provide support for load balancing and high availability. MultiPools make it easier for an application to switch to another RDBMS for distributed processing or during a failover situation.

For more information, see Programming WebLogic JDBC.

JDBC-based Persistence

A new column, wl_max_inactive_interval, has been added to the wl_servlet_sessions table used for JDBC-based persistence. For information on the wl_servlet_sessions table, see the section "Using a Database for Persistent Storage".

JavaMail

WebLogic Server 6.1 includes an implementation of the JavaMail Specification. This is the standard reference implementation of the JavaMail Specification. For more information, see Developing WebLogic Server Applications

Java Transaction API (JTA)

WebLogic Server 6.1 supports distributed transactions and the two-phase commit protocol with a specification-compliant JTA implementation. This implementation works with any certified XA-compliant resource such as WebLogic JMS and the WebLogic jDriver for Oracle.

For more information, see Programming WebLogic JTA.

JMS

The following are new or improved features of JMS.

Asynchronous JMS

Now you can disable synchronous writes to JMS File Stores. This capability results in much improved performance at the expense of reliability. If JMS reliability is not critical to your application, you may benefit from this feature. For more information, see Programming WebLogic JMS.

Durable Subscription Management

A RuntimeMBean has been added for managing JMS durable subscriptions (JMSDurableSubscriberRuntimeMBean). Use this MBean to perform simple management tasks, such as monitoring, deleting, or modifying durable subscriptions, from the WebLogic Server Administration Console.

Redelivery Delay

You can delay the redelivery of messages when a temporary, external condition prevents an application from handling a message properly. When a message is rolled back or recovered, the RedeliveryDelay is the amount of time a message is delayed before redelivery is attempted.

If JMS immediately redelivers the message, the condition may not be clear and the application still may be unable to handle the message. Configuring an application for a RedeliveryDelay addresses this issue.

Time To Deliver

You can schedule message deliveries to an application for specific times in the future. Message deliveries can be deferred for short periods (such as seconds or minutes) or for long stretches (such as hours later for batch processing). You can also specify a relative TimeToDeliver (in milliseconds), which WebLogic JMS will then compute into an absolute DeliveryTime for a message. Until that DeliveryTime, the message is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.

Redelivery Limit

You can set a limit on the number of times that WebLogic JMS will attempt to redeliver a message to an application. Once WebLogic JMS fails to redeliver a message for a specific number of times, the message can be redirected to an ErrorDestination queue. If no ErrorDestination is configured, then the message is dropped.

JSP

The following JSP features are included with WebLogic Server 6.1:

- Options to the WebLogic JSP compiler (weblogic.jspc) that allow you to compile JSPs that use EJBs in Web Applications. For details, see the section "JSP Descriptor Element".

- New form validation tags are now available. The validation tags are a convenient means of validating the entries submitted from an HTML form. For more information, see "Using JSP Form Validation Tags".

- A tool to create a JSP tag library from an EJB jar file. For more information, see "Using the WebLogic EJB to JSP Integration Tool".

- JSP 1.2 Support

  Support for the following features of the JSP 1.2 specification from Sun Microsystems has been added. Version 1.2 of the specification is a proposed final draft of the specification and is subject to change. If you are planning to use JSP 1.2 features in your application, note that the specification has not been finalized and could change in the future.

  - <jsp:include flush="false">. Allows you to control when the buffer is flushed for an included JSP. For more information, see the section "Including Requests".

  - TryCatchFinally interface for a JSP tag. For more information, see Handling Exceptions within a Tag Body.

  - Tag Library Validator allows you to write a class to validate a JSP. For more information, see Using a Tag Library Validator.

  - IterationTag class. For more information, see Iteration Over a Body Tag.

  - Definition of variables in the tag library descriptor. For more information see Defining Scripting Variables.

Security

WebLogic Server 6.1 security functionality includes:

- JAAS login and realm-based authentication support

- Enhanced support for generating audit trails

- ACL improvements

- Password-guessing protection

- Denial-of-service protection

- Improved administration of the RDBMS realm

For more information, see Programming WebLogic Security.

Default and Custom Login Modules

WebLogic Server uses the default LoginModule (weblogic.security.internal.ServerLoginModule) to gather authentication information during server initialization. To replace the default Login module, edit the server.policy file and replace the name of the default Login module with the name of a custom Login module.

Optionally, custom login modules can be specified in the server.policy file ahead of the default LoginModule. The JAAS implementation in WebLogic Server uses Login modules in the order in which they are defined in the server.policy file. The default Login module checks for existing system user authentication definitions prior to execution and does nothing if they are already defined.

The default Login module is required to define JVM properties for both the system username and password. These properties are specified as weblogic.management.username and weblogic.management.password respectively. In order to use a custom Login module, these properties must be set accordingly.

Servlets and Web Applications

The following new features and changes apply to servlets and Web Applications:

- Web Application Events (Servlet 2.3 only)

  Web Application Events provide notifications of a change in state of the servlet context (each Web Application uses its own servlet context) or of an HTTP session object. You can write event listener classes that respond to these changes in state. For more information, see Using Application Events and Listeners.

- Filters (Servlet 2.3 only)

  A filter is a Java class that is invoked in response to a request for a resource in a Web Application. These resources can include Java Servlets, JavaServer Pages (JSPs), or static resources such as HTML pages or images. A filter intercepts the request and can examine and modify the response and request objects or execute other tasks. For more information, see Using Filters.

- Single sign-on between Web Applications. This means the server tracks users at the Web Server level and not the Web Application level, as mandated by the Servlet 2.2 specification.

- The format for cookies:

  - Cookies created by a WebLogic Server 6.0 without a Service Pack will not be recognized by WebLogic Server 6.1.

  - Cookies no longer include the context path of a Web Application. This change allows for a single authentication to be used for all Web Applications in a domain. If you need a Web Application to use a unique authentication or to generate a cookie that is unique to the Web Application, you can specify a cookie name for each Web Application in the weblogic.xml deployment descriptor. For more information, see Multiple Web Applications and Cookies.

  - The delimiter used in the cookie has changed from "/" and "|" to "!". The "/" delimiter caused URL rewriting to fail and the "|" delimiter caused Wireless Application Protocol (WAP) gateways to fail. Both URL rewriting and WAP now function correctly with WebLogic Server.

Version 2.3 of the Servlet Specification from Sun Microsystems is a proposed final draft of the servlet specification and is subject to change. If you are planning to use any features introduced with version 2.3 in your application, note that the specification has not been finalized and could change in the future.

SNMP

WebLogic Server 6.1 can function as a Simple Network Management Protocol (SNMP) agent. The WebLogic SNMP agent runs as a service that responds to requests from SNMP managers and sends SNMP trap notifications to SNMP managers. The WebLogic SNMP agent uses standard Java Management Extension (JMX) interfaces to access WebLogic resources. For more information, see the WebLogic SNMP Management Guide.

System Administration

Installation

WebLogic Server 6.1 includes an installation program that makes it easier to install WebLogic Server on both Windows and UNIX systems. The installer unpacks the distribution, performs basic configurations, and sets up shortcuts for using WebLogic Server. In addition, the JDK is included in the package so that the server is ready to run.

For details, see the WebLogic Server Installation Guide.

Internationalization

WebLogic Server 6.1 can deliver content in any language, including those languages that require double-byte character sets. For information about using the new internationalization API, see the WebLogic Server Internationalization Guide.

In addition, a Kanji version of WebLogic Server 6.1 will be available. For more information, contact your BEA sales representative.

Administration Console

Improvements to management architecture enable you to make dynamic configuration changes to running instances of WebLogic Server. A Web-based Administration Console is your window into the WebLogic Administration Service, an implementation of the Java Management Extension (JMX) standard. Using the Administration Console, you can configure attributes, deploy applications and components, monitor resource usage, view log messages, edit deployment descriptors and .xml files, and perform other management activities. Administration Console features include:

- Browser interface

- Centralized user and security management

- Dynamic configuration management

- Editing tool for deployment descriptors of J2EE Archives

- Administrative domains

- Management of one or more clusters

- A centralized application repository

- Metrics on the status of servers

- Centralized access to log messages for all servers in a domain

For more information, see the WebLogic Server Administration Guide.

Production Mode and Development Mode

There is now a flag that can be used to switch between production and development modes. When the server starts, it loads and deploys any applications that have configuration information in the config.xml file, whether you are using production or development mode. If you are running in development mode, the server will also deploy or redeploy any applications stored or placed in the ..\applications directories after startup. This is called dynamic deployment and is useful when you are developing your applications. If you shut down the server, the configuration information for any applications that were dynamically deployed is written to the config.xml file in the application's domain. The production/development flag can be added to the startup script for your domain. If it is not added, development mode will be activated. To change the mode:

1. With a text editor, open the start script for your domain.

2. Edit the line that begins set STARTMODE= to add the value true or false. True is for production mode, and false is for development mode.

Tools

WebLogic Server 6.1 includes the weblogic.refresh tool, which lets you refresh static components of an application without redeploying the application. Use weblogic.refresh to refresh, add, or delete static files such as:

- JSPs

- XML files

- HTML files

- Image files such as .gif and .jpg

- Text files

WebLogic Tuxedo Connector

In WebLogic Server Release 6.1, the WebLogic Tuxedo Connector has the following limitations:

- Does not support dynamic configuration changes to WebLogic Tuxedo Connector gateway

- Does not support View buffers.

- Does not support in-bound RMI/IIOP transactions from a Tuxedo application.

- Does not support clustering. Only one instance of WebLogic Tuxedo Connector can be used in a clustered environment.

- Does not support Tuxedo 6.5 running on VMS, AS/400, and OS/390 platforms.

WebLogic-Tuxedo Interoperability

WebLogic Tuxedo Connector (WTC) provides interoperability between WebLogic Server applications and Tuxedo ATMI, CORBA Java, and CORBA C++ server applications. WTC tBridge functionality provides Tuxedo /Q and JMS advanced messaging services. For more information, see the WebLogic Tuxedo Connector Guide.

BEA WebLogic C++ Client

WebLogic Server 6.1 SP3 interoperates with C++ clients using the Tuxedo 8.0 C++ Client ORB. Tuxedo release 8.0 RP 56 and above is required. WebLogic Server users should contact their BEA Service Representative for information on how to obtain the Tuxedo C++ Client ORB. For more information on how WebLogic Server interoperates with a Tuxedo C++ Client ORB, see RMI-IIOP with Tuxedo and Tuxedo Clients.

XML

WebLogic Server 6.1 supports XML as an essential component. JSPs can be used to generate and consume XML between servers or between a server and clients. WebLogic Server 6.1 supports XSL processing tags for JSPs. EJBs use XML to describe deployment properties, which provides data portability. The server provides an XML schema repository for DTDs, managed by the Administration Console.

The XML subsystem of WebLogic Server 6.1 includes the following new features and improvements:

- The JAXP API is upgraded to 1.1.

- WebLogic server includes a high-performance XML parser, specifically designed to parse small-to-medium sized XML documents. This XML parser is non-validating and can be used only in SAX mode.

- The built-in Apache Xerces parser is upgraded to 1.3.1.

- The built-in Apache Xalan transformer is upgraded to 2.0.1.

- The XML Registry is divided into two distinct sections: one to configure parsers and transformers and one to configure external entity resolution. As a result, the XML Registry is easier and more intuitive to use.

- The XML Registry now includes the ability to cache external entities accessed via URLs on the local computer, in addition to copying entities locally. The external entity cache can be configured and monitored using the XML Registry.

- The 6.0 XML feature of generating custom parsers is deprecated. Instead, programmers should use the WebLogic high-performance XML parser where previously they used custom generated parsers.

For more information on XML, see Programming WebLogic XML.

XML Editor

WebLogic Server now provides a simple, user-friendly tool for creating and editing XML files. It can validate XML code according to a specified DTD or XML Schema. The XML editor can be used on Windows or Solaris machines and can be downloaded from dev2dev Online.

Web Services

The current WebLogic ServerTM release includes a new feature: WebLogic Web Services. Web services are an emerging family of Web/XML standards and conventions that enable loosely coupled application-to-application interoperability across programming models. The Web services implementation in WebLogic Server 6.1 provides simple extensions to the J2EE programming model that enable J2EE applications to be exposed as Web services. WebLogic Web Services are standards-based and interoperate with other Web services hosted on non-WebLogic servers. Both Java and non-Java client applications (such as Microsoft SOAP Toolkit clients) can invoke WebLogic Web Services. For detailed information about developing and invoking WebLogic Web services, see Programming WebLogic Server WebServices.

Deprecated Features and APIs

The following features are deprecated in WebLogic Server 6.1 and will not be supported in the future:

- weblogic.db.jdbc.EventfulTableDataSet

- WebLogic WorkSpaces

- WebLogic Events

- WebLogic Time

- WebLogic JDBC t3 driver

- ZAC

For a list of deprecated WebLogic Server classes, see http://e-docs.bea.com/wls/docs61/javadocs/deprecated-list.html.

Documentation and Examples

The examples included with WebLogic Server 6.1 now include ant build scripts. These scripts accompany the examples as build.xml files and can be run on any platform supported by WebLogic Server 6.1. Execute these build scripts on a command line by locating the proper directory for that example and typing:

ant

The following documentation and examples are new to WebLogic Server 6.1:

- New documentation for the config.xml file is in WebLogic Server Configuration Reference

- Performance and tuning information for WebLogic Server 6.1 is in the BEA WebLogic Server Performance and Tuning Guide.

- WebLogic Web Services documentation and examples are in the Programming WebLogic Web Services Guide.

- WebLogic Server 6.1 can function as a Simple Network Management Protocol (SNMP) agent. See the new SNMP Management Guide.

- JCA examples and documentation on Managing the WebLogic J2EE Connector Architecture are provided in the WebLogic Server Administration Guide.

- Assembling and Configuring Web Applications provides all the configuration, assembly, and deployment information for Web Applications in one book. Some of this information was previously located in the Administration Guide and in Developing WebLogic Server Applications.

- Several examples demonstrating wireless connectivity are available with WebLogic Server 6.1.

- An extensive migration tutorial demonstrates how applications deployed on earlier releases of WebLogic Server can be adapted to WebLogic Server 6.1.

- A new example package demonstrates Oracle's delete cascade. It uses the one-to-many relationships between two EJBs written to the EJB 2.0 specification.

- Auto Primary Key Generation EJB examples have been added. These examples automatically generate primary keys during insertions into a database table.

- For documentation and examples, see the WebLogic Tuxedo Connector documentation.

WebLogic Server Tour

The WebLogic Server Tour is revised. It provides an overview of WebLogic Server using the Pet Store application to demonstrate features. The Tour is available from the Start menu. The Pet Store is now based on version 1.1.2 of Sun's Java Pet Store and has been upgraded to use build scripts with Ant 1.3.

J2EE and Standards Topics

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 6.1 includes the 1.3.1rc2 JDK from Sun Microsystems.

BEA WebLogic Server 6.1 is the first e-commerce transaction platform to implement advanced J2EE 1.3 features. To comply with the rules governing J2EE, BEA Systems provides two separate downloads: one with J2EE 1.3 features enabled, and one that is limited to J2EE 1.2 features only. Both downloads offer the same container and differ only in the APIs that are available.

WebLogic Server 6.1 with J2EE 1.2 Plus Additional J2EE 1.3 Features

With this download, WebLogic Server defaults to running with J2EE 1.3 features enabled. These features include EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0. When you run WebLogic Server 6.1 with J2EE 1.3 features enabled, J2EE 1.2 applications are still fully supported. The J2EE 1.3 feature implementations use non-final versions of the appropriate API specifications. Therefore, application code developed for BEA WebLogic Server 6.1 that uses the new features of J2EE 1.3 may be incompatible with the J2EE 1.3 platform supported in future releases of BEA WebLogic Server.

The sections below list the J2EE 1.3 API classes and deployment descriptors that are not implemented in WebLogic Server 6.1.

Enterprise Java Beans Deployment Descriptors

WebLogic Server 6.1 fully implements all EJB 2.0 deployment descriptors defined in Sun Microsystem's ejb-jar.xml document type definitions (DTD) file with the following exceptions:

- exclude_list

- unchecked

- run_as

Note: The ejb-jar.xml document type definitions (DTD) file is part of Sun Microsystem EJB 2.0 specification.

JDBC API Classes

API | Class or Interface | Methods not Implemented | Notes
--- | --- | --- | ---
java.sql | CallableStatement | getResultSet(int parameterIndex) | Implemented as a method for the OracleCallableStatement Oracle extension; you must use a JDBC driver that supports the OracleCallableStatement extension, such as the Oracle Thin Driver.
Driver | getPropertyInfo(java.lang.String url, java.util.Properties info) | Not Implemented

JSP 1.2 API Classes

API | Class | Differs from J2EE 1.3
--- | --- | ---
javax.servlet.jsp | java.beans.Beans | The jsp:id mechanism has not been implemented

Note: The following feature has not been implemented:

A JAR containing a packaged tag libraries can be dropped into the WEB-INF/lib directory to make its classes available at request time.

JSP 1.2 Deployment Descriptors

- The <listener> element in the taglib.tld is not registered with the web application.

- The <example> element in the taglib.tld is not honored.

- WebLogic Server 6.1 uses the older signature of the TaglibraryValidator.validate() method which returns a string

Servlet API Classes

API | Class | Differs from J2EE 1.3
--- | --- | ---
javax.servlet | Filter | The Filter interface that we support has following methods: doFilter(ServletRequest,ServletResponse,FilterChain) getFilterConfig() Return the FilterConfig for this Filter. setFilterConfig(Fil-terConfig) The container calls this method when the Filter is instantiated and passes in a Filter-Config
ServletContext | Added the directory argument (String) in the ServletContext.getResourcePaths() method
ServletContextAttributesListener | The name in the final specification has been changed to: ServletContextAttributeListener
javax.servlet.http | HttpServletResponse | Added the status code 307 (temporary redirect) to HttpServletResponse
HttpSession | The getServletContext() method has been added to HttpSession
HttpSessionAttributesListener | The name in the final specification has been changed to: HttpSessionAttributeListener

Servlet Deployment Descriptors

WebLogic Server 6.1 fully implements all Servlet 2.3 deployment descriptors with the following exceptions:

- ejb-local-ref

- run_as

WebLogic Server 6.1 with J2EE 1.2 Certification

With this download, WebLogic Server defaults to running with J2EE 1.3 features disabled and is fully compliant with the J2EE 1.2 specification and regulations.

Product CD Installers for J2EE 1.2 and 1.3

In addition to being available at http://commerce.bea.com/downloads/products.jsp, both distributions are provided on the WebLogic Server 6.1 product CD. (On Windows machines, the installer for WebLogic Server with J2EE 1.3 features enabled starts automatically when you insert the CD.)

Standards Support

Standard | Version
--- | ---
HTTP | 1.1
J2EE Connector Architecture | 1.0
J2EE EJB | 2.0
J2EE JDBC | 2.0
J2EE JNDI | 1.2
J2EE JSP | 1.1
J2EE JTA | 1.0.1
J2EE JMS | 1.0.2
J2EE RMI | 1.0
RMI/IIOP | 1.0
J2EE Servlet | 2.2
LDAP | 2
SSL | 3
X.509 | 3

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