Release Notes
|
 |
 |
|
 |
 |
Welcome to BEA WebLogic Server 9.0, the most significant WebLogic Server® release to date. Fully compliant with J2EE 1.4, WebLogic Server 9.0 tackles the biggest challenge facing enterprise networks today: reducing overall cost of management and operations while delivering high reliability, continuous uptime, scalability, and mission-critical integration solutions.
Note: For information on current known problems and problems that are now resolved, see WebLogic Server Known and Resolved Issues.
The following sections describe new and changed functionality in WebLogic Server 9.0:
WebLogic Server 9.0 is fully compliant with the J2EE 1.4 Specification. This release implements and extends the latest J2EE standards -- Enterprise Web Services 1.1, JMS 1.1, JMX 1.2, JDBC 3.0, Connector Architecture 1.5, EJB 2.1, and many more -- to deliver unparalleled quality-of-service across the enterprise. The following sections summarize innovations in key areas of functionality. For detailed standards support information, see Standards Support.
WebLogic Server 9.0 focuses on simplifying and streamlining the day-to-day management of production systems with minimal disruption to live production environments. A comprehensive, centralized diagnostics service lets administrators identify and resolve issues in real time, and accommodates the integration of third-party analytic tools. This release of WebLogic Server introduces a more extensible, "portalized" Administration Console as well as a tightly controlled, predictable process for managing changes to a domain's configuration regardless of the configuration tool you use. A new scripting tool, a simplified domain directory structure, and modular deployment capabilities automate and facilitate application configuration and deployment.
See System Administration and Management.
Out-of-the-box support for WAN and MAN failover address catastrophic data center failures. Overall server performance improves greatly in WebLogic Server 9.0, with automated server migration and provisioning of services, policy-driven processing, self-tuning capabilities, increased overload protection, and cross-cluster failover.
See Server Reliability, Availability, Scalability, and Performance.
Now a J2EE standard, Web Services increase developer flexibility and choice by providing a common runtime environment and industry-standard support for Java annotations and Web Services extensions. The WebLogic Server implementation of Web Services 1.1 helps developers respond more effectively to changing business requirements, with true asynchronous messaging support for conversational applications; interoperability features designed for enterprise service-oriented architecture (SOA); and improved XML processing. Developers can leverage WebLogic Web Services to rapidly create, deploy, and adapt secure and fully interoperable Enterprise Web Services.
See J2EE Standard Web Services.
WebLogic Server 9.0 implements cross-domain communication; bi-directional transactions from Enterprise Information Systems; automatic destination migration for high availability; message store-and-forward for improved reliability; and tightly controlled order-of-message delivery. In addition, this release improves management and performance of enterprise and messaging-intensive applications.
See Resource Adapters.
The following sections describe new and changed features that affect overall server administration and management:
The following sections describe key changes and improvements to WebLogic Server core operations:
A new life cycle state, ADMIN, facilitates application redeployment, maintenance, and troubleshooting. In the ADMIN state, WebLogic Server is running, but available only for administration operations, so you can perform server and application-level administration tasks without risk to running applications.
See Understanding Server Lifecycle in Managing Server Startup and Shutdown.
Developers can define properties as work contexts and can pass properties without explicitly including them in a remote call. A work context is propagated with each remote call, which allows the called component to add or modify properties defined in the work context. Similarly, the calling component can access the work context to obtain new or updated properties.
Work contexts facilitate diagnostics monitoring, application transactions, and application load-balancing, all of which require communication with remote components. They also provide information to third-party components.
Work contexts can be used by both clients and servers, and are enabled separately for each.
See Developing WebLogic Server Applications.
In addition to managing external network traffic, network channels can now manage network traffic between server instances. Other new and improved network channel capabilities include:
See Configuring WebLogic Server Environments.
The WebLogic Persistent Store is a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence, especially subsytems that require the creation and deletion of short-lived data objects, such as transactional messages for JMS Servers. Each server instance in a domain has a default persistent store that requires no configuration and that can be used simultaneously by subsystems that do not require explicit selection of a particular store, but can use the system's default storage. These subsystems include JMS Servers, Web Services, EJB Timer services, Store-and-Forward services, and the JTA Transaction Log (TLOG). Optionally, administrators can configure dedicated file-based stores or JDBC-accessible stores to suit their environment.
See Using The WebLogic Persistent Store in Configuring WebLogic Server Environments.
The WebLogic Store-and-Forward (SAF) service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. For example, with the SAF service, an application that runs on or connects to a local WebLogic Server instance can reliably send messages to a destination that resides on a remote server. If the destination is not available at the moment the messages are sent, then the messages are durably saved on a local server instance, and are forwarded to the remote destination once it becomes available.
WebLogic JMS utilizes the SAF service to enable local JMS message producers to reliably send messages to remote JMS queues or topics. WebLogic Web Services build the implementation of the Web Services Reliable Messaging (WSRM) standard on top of the SAF service.
See Configuring and Managing WebLogic Store-and-Forward.
The WebLogic Server Administration Console has been completely redesigned in the current release. The Administration Console is now built on the WebLogic Portal Framework, which makes it more open and more readily extensible, as described in Portal Application Support in the Administration Console. Other new features include:
The WebLogic Server Administration Console is completely redesigned in this release. Prior to 9.0, the Administration Console used JSPs and its own framework to render its user interface. Now the Console uses JSPs, the WebLogic Portal framework, Apache Struts, Apache Beehive, and other open technologies.
You can extend the Administration Console as you can extend portal applications generally, except that the Administration Console does not support JSR 168 or Web Services for Remote Portlets (WSRP). In addition to adding and replacing content, you can add a node to the navigation tree and change colors, branding images, and other aspects of the Console's appearance.
Note: Because the new architecture is so different, WebLogic Administration Console extensions built for prior releases of WebLogic Server will not function in 9.0. Although you might be able to reuse the content and some logic in the JSPs that you created in previous Administration Console extensions, BEA no longer supports the APIs or JSP tag libraries that it provided for extensions prior to 9.0. In addition, you must now define portlets as the container for your JSPs.
Improvements in change management enable you to distribute configuration changes throughout a domain securely, consistently, and predictably, regardless of whether you are using the Administration Console, WebLogic Scripting Tool (WLST), JMX, or other APIs.
To protect your changes and to prevent others from making changes, a new region in the Administration Console called the Change Center requires you to lock the Console before you begin to modify a domain configuration.
When you finish making changes, you save and distribute them to all server instances in the domain, or you can roll back changes and release the lock. Each server determines whether it can accept the change. If all servers can accept the change, they update their working configuration tree and the change is completed. If one or more servers do not accept the change, the changes are not made in any server, thus avoiding an incomplete intermediate state. This feature helps ensure that WebLogic Server configuration information is correct and consistent at all times.
WebLogic Server controls configuration changes in generally the same manner, whether the changes are implemented using the Administration Console, the WebLogic Scripting Tool, or the Configuration Manager service and JMX APIs:
WebLogic Scripting Tool (WLST) is a new command-line interface that you use to configure WebLogic Server instances and domains, and to manage and persist WebLogic Server configuration changes.
config.xml file. Based on the Java scripting interpreter, Jython, WLST interprets commands interactively, supplied one-at-a-time from a command prompt, or in batches, supplied in a file (script), or embedded in your Java code. You can use the scripting tool online (connected to a running server) and offline (not connected to a running server).
Note: BEA Systems recommends that you use WLST in place of weblogic.Admin and wlconfig. See Restricted and Deprecated Utilities: wlconfig and weblogic.Admin.
The new WebLogic Diagnostic Service integrates all diagnostics features and functionality into a centralized, unified framework that enables you to create, collect, analyze, and archive diagnostic data in a standard format. The Diagnostic Service provides more visibility into and control of server runtime performance and applications, allowing you to diagnose and isolate faults as they occur.
The following sections describe WebLogic Diagnostic Service functionality. For more detailed information, see Configuring and Using the WebLogic Diagnostic Framework.
The WebLogic Diagnostic Service provides a dynamic view of metrics, data events, and logging and debug information. It also exposes new diagnostic data in areas of the server that were not previously exposed.
Previous releases of WebLogic Server included a number of independent logging capabilities, such as the standard server and domain logs, JDBC log, and access log. The logs relied on different implementations and thus did not benefit from the same services and facilities, such as rotation, as the standard log. These logging solutions are now unified by a single implementation that provides the same qualities of service for all server logging. You can configure the WebLogic Diagnostic Service to collect, analyze, and archive all events generated by WebLogic Logging Services.
Instrumentation capabilities in the Diagnostic Service enable you to:
The diagnostic context is a means of reconstructing transactional events and of correlating events based on the timing of the occurrence or on logical relationships. You can reconstruct a thread of execution from request to response, or generate diagnostic information only when contextual information in the diagnostic context satisfies certain criteria. This capability keeps the volume and overhead of generated information to manageable levels.
Most event collection is accomplished by designating key points in the application flow and then monitoring every request that passes through those points. However, to minimize collection volume and facilitate event isolation, it is sometimes preferable to capture only events for a single request or requests coming from a single client. The WebLogic Diagnostic Service allows you to mark, or dye, a particular request in such a way that the WebLogic Diagnostic Service can determine whether it should be monitored. The WebLogic Diagnostic Service marks requests when they enter the system by setting flags in the diagnostic context, discussed in Diagnostic Context for Reconstruction and Correlation of Events.
The Harvester component of the WebLogic Diagnostic Service can be configured to collect metrics contained in server MBeans. Additionally, because the WebLogic Diagnostic Service enables you to harvest metrics from custom MBeans that you provide, you can also collect metrics from your own applications.
The Server Image Capture component of the WebLogic Diagnostic Service creates a diagnostic snapshot from the server, either on-demand or automatically. The most common sources of server state— configuration, Log Cache, WorkManager, JNDI state, and harvestable data— are captured, as well as images from JMS, JDBC, EJB, JNDI, and other server subsystems.
When a server fails and recovers repeatedly over a short period, for example, in storm-related power failures, system administrators can also specify an image-lockout period, which prevents the server from repeatedly capturing and persisting similar diagnostic images that unnecessarily consume system resources.
Customers who develop software for trapping, routing, and handling of events from systems within their enterprise can configure the Diagnostic Service to analyze these custom application events and automatically generate notifications to alert system administrators. This capability enables a tighter integration with legacy monitoring frameworks in larger customer environments.
To monitor WebLogic Server, watches can be configured to detect specific conditions and to analyze logging and debugging log records, data events, and harvested metrics. Watches can also trigger different types of notification listeners, including Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP), Java Management Extensions (JMX), and Java Message Service (JMS).
All data collected from the server and applications running on it are persisted to permanent storage. The Data Accessor component provides access to all current and historical data collected by the WebLogic Diagnostic Service, including data events, log records, and harvested metrics. You can access archived data online (on a running server) and offline (after the server shuts down).
The WebLogic Diagnostic Service provides standard integration capabilities for third-party monitoring and analytic tools:
The WebLogic Diagnostic Service is compatible with existing diagnostic tools and capabilities, such as instrumentation, developed by BEA partners. The WebLogic Diagnostic Service makes it easier for partners to integrate their tools, while BEA Systems takes ownership of the integration interfaces and provides support, documentation, and an improved quality of service.
WebLogic Logging Services provide several new features and configuration options.
Enhancements to LogMBean interfaces let you control logging output by setting the severity level and filters on both loggers and handlers.
In earlier versions of WebLogic Server, system administrators and developers had only programmatic access to loggers and handlers. In this release, you can configure handlers by using MBeans, eliminating the need to write code for most basic logging configurations. The Administration Console and WebLogic Scripting Tool (WLST) provide an interface for interacting with logging MBeans. Loggers are configured only through the API.
WebLogic Server supports Jakarta Project Log4j. In the Administration Console, you specify Log4j or the default Java Logging implementation. Alternatively, you can configure Log4j logging through the LogMBean interface using the LogMBean.isLog4jLoggingEnabled attribute.
The Jakarta Commons Logging APIs provide an abstraction layer that insulates users from the underlying logging implementation. WebLogic Server provides an implementation of the Commons LogFactory interface, letting you issue requests to the server Logger by using this API.
See Configuring Log Files and Filtering Log Messages.
WebLogic Server 9.0 includes the following changes to log file locations:
logs directory below the server instance root directory; for example, root-directory\servers\server-name\logs\server-name.log.logs directory. The default name and location for the domain log file is root-directory\servers\AdminServer-name\logs\domain-name.log. LogFileRotationDir property of the LogFileMBean from the command line.In this release of WebLogic Server, you can use WebLogic-specific deployment descriptors to configure Web application and resource adapter logging behavior. The logging configuration deployment descriptor elements define similar attributes used to configure server logging through the LogFileMBean interface, such as the log file name, location, and rotation policy.
Similarly, logging services are provided to J2EE resource adapters for ManagedConnectionFactory scoped logging. You configure the log file name, location, and rotation policy for resource adapter logs through the weblogic-ra.xml deployment descriptor.
See Using WebLogic Logging Services for Application Logging.
Data storage has changed as follows in WebLogic Server 9.0:
config.xml, in the new domain config directory. Configuration files are archived in JAR files in the configArchive directory under the domain directory. These changes affect recommended backup procedures. See Avoiding and Recovering From Server Failure in Managing Server Startup and Shutdown.Configuration data such as JDBC resource names, security data, persistent store, and the XML schema for the config.xml file may have changed since WebLogic Server 9.0 BETA. If you were using WebLogic Server 9.0 BETA, your config.xml file is probably not usable in WebLogic Server 9.0 GA.
The weblogic.Admin utility is deprecated as of WebLogic Server 9.0. Both weblogic.Admin and wlconfig are now restricted as follows:
BEA Systems recommends that you use the WebLogic Scripting Tool (WLST) for equivalent functionality. See WebLogic Scripting Tool.
WebLogic Server 9.0 significantly improves server and cluster RASP:
Note: Server Migration is not supported on all platforms. See Server Migration in Supported Configurations for WebLogic Server 9.0.
WebLogic Server now supports automatic and manual migration of a clustered server instance and all the services it hosts from one machine to another. This feature is designed for environments with high availability requirements. Use the server migration capability to:
See Server Migration in Using WebLogic Server Clusters.
WebLogic Server 9.0 supports part of the BEA and IBM Joint Specifications (CommonJ) described at http://dev2dev.bea.com/technologies/commonj/index.jsp. In particular, this release implements the Timer and Work Manager 1.1 Specification, available at http://dev2dev.bea.com/technologies/commonj/twm/index.jsp.
The Timer API provides a simple API that applications can use to create and use timers managed within the application server, and is a recommended alternative to the J2SE java.util.Timer class.
The Work Manager API enables an application to break a single request task into multiple work items, and assign those work items to execute concurrently by using multiple Work Managers configured in WebLogic Server. (Applications that do not need to execute concurrent work items can also use configured Work Managers by referencing or creating Work Managers in their deployment descriptors or, for J2EE Connectors, by using the JCA API.) See also Server Self-Tuning for Production Environments for more information about the new Work Manager tuning strategies.
The state of an HTTP session running on a server instance in one cluster can be replicated on a server instance in a different WebLogic Server cluster. The clusters can be located on different LANs within the same metropolitan area network (MAN), or can be in geographically distant locations—in different cities or states—within a wide area network (WAN). Upon a failure of the primary server instance, another member of the same cluster can recover the session data from the remote instance (in another cluster) and make it available in the primary cluster. If no members of the cluster in which the primary failed are available, the request can fail over to the remote cluster hosting the session replica.
Here are two example environments in which WebLogic Server cross-cluster session replication features are useful:
See Using WebLogic Server Clusters.
New self-tuning capabilities simplify the process of configuring WebLogic Server for production environments with service-level requirements that vary over time or by application. Self-tuning helps prevent deadlocks during periods of peak demand. Self-tuning features are also useful if your WebLogic Server environment hosts multiple applications with different performance and availability requirements. For example, you can allocate a greater percentage of resources to a user-facing order processing application than to a back-end inventory management application.
The new queue strategy enables administrators to allocate processing resources and manage performance more effectively, by avoiding the effort and complexity involved in configuring, monitoring, and tuning custom execute queues.
Key self-tuning features in WebLogic Server 9.0 include:
See Configuring WebLogic Server Environments.
Many enhancements make Node Manager more versatile and easier to use:
See Using Node Manager to Control Servers in Managing Server Startup and Shutdown.
In this release, you can still explicitly define a cluster address, but if you do not, WebLogic Server dynamically generates the cluster address for each request. This capability eases the configuration effort, and ensures that the cluster address correctly reflects the cluster membership at startup. See Cluster Address in Using WebLogic Server Clusters.
New overload features protect a server instance from out-of-memory (OOM) exceptions and execute queue overloads, thus increasing the availability of a server or a cluster.
See Configuring WebLogic Server Environments.
Web Services are now a J2EE standard, which has resulted in many changes between 8.1 and 9.0 WebLogic Web Services.
WebLogic Server 9.0 includes the following changes and new features:
J2EE 1.4 introduces a standard Java component model for authoring Web Services, with new specifications such as Web Services for J2EE, Version 1.1 (JSR-921, the 1.1 maintenance version of JSR-109) and Java API for XML Registries (JAX-R), as well as updated JAX-RPC and SAAJ specifications.
As a result, the programming model used to create WebLogic Web Services has also changed. The model now takes advantage of the powerful new metadata annotations feature introduced in Version 5.0 of the JDK. Additionally, the runtime environment upon which WebLogic Web Services run now supports the Web Services for J2EE, Version 1.1 specification.
The entire 8.1 Web Services runtime, which includes the weblogic.webservice.* APIs, is deprecated. You should now use both the new programming model (JWS files with accompanying Ant task) and the weblogic.wsee.* packages instead. See the javadocs for the full list of public WebLogic APIs. See Programming Web Services for WebLogic Server for information about the new 9.0 WebLogic Web Services runtime.
Note: 8.1 WebLogic Web Services continue to run, without any changes, on Version 9.0 of WebLogic Server because the 8.1 Web Services runtime is still supported in 9.0, although it is deprecated and will be removed from the product in a future release. For this reason, BEA highly recommends that you upgrade your 8.1 Web Service to 9.0. See Upgrading an 8.1 Web Service to 9.0.
There is an additional small change in the Web Services of the Avitek Medical Records (MedRec) sample application between version 8.1 and 9.0. In 8.1, the MedRec application used a non-public API in the weblogic.webservice.tools.wsdlp package. In 9.0, this package has moved to weblogic.webservice.wsdl and is deprecated. The Web Services in the 9.0 Medrec application use the 9.0 Web Services runtime and programming model.
See Differences Between 8.1 and 9.0 WebLogic Web Services.
The programming model used to create 9.0 WebLogic Web Services is based on the new JDK 5.0 metadata annotations feature. In this model, the implementation of your Web Service is a Java file that uses Java Web Service (JWS) annotations. These JWS annotations are a combination of standard ones, defined by the Web Services Metadata for the Java Platform specification (JSR-181), and WebLogic-specific ones.
Note: Although using JWS annotations is the preferred programming model for creating WebLogic Web Services, you can also create one manually by programming the EJB or Java class that implements the Web Service and creating all the required components, such as the Web Service deployment descriptors and the WSDL file.
The Web Services for J2EE, Version 1.1 specification defines the standard J2EE runtime architecture for implementing Web Services in Java.
See Anatomy of a WebLogic Web Service.
WebLogic Web Services support a variety of asynchronous features:
WebLogic Web Services support the digital signature and encryption of request and response SOAP messages generated during invocation of a Web Service. This capability derives from conformance with the following OASIS Standard 1.0 Web Services Security specifications:
You configure message-level security through security WS-Policy statements, as specified by the WS-Policy specification.
See Configuring Security.
As in previous releases, WebLogic Web Services support a full set of built-in XML Schema, Java, and SOAP types, as specified by the JAX-RPC 1.1 specification, that you can use in your Web Service operations without performing any additional programming steps.
Additionally, you can define a variety of XML and Java data types, including com.bea.xml.XMLBeans, as input parameters and return values for your Web Service. The WebLogic Web Services Ant tasks automatically generate the data binding components needed to convert the user-defined data types between their XML and Java representations.
See Data Types and Data Binding.
WebLogic Web Services 9.0 implement the WS-Policy specification, which provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web Service. In this release, policy files are used only for configuring the Web Services reliable messaging and message-level security features.
or information on how WS-Policy files are used to configure security and reliable messaging, see Use of WS-Policy File for Message-Level Security Configurationand Use of WS-Policy Files for Reliable SOAP Message Configuration.
A set of Ant tasks handle JWS annotated files and integrate them into the WebLogic split development directory environment. This development environment consists of a directory layout and associated Ant tasks that help you repeatedly build, change, and deploy J2EE applications, including Web Services.
See Web Services Ant Task Reference.
Web Services in WebLogic Server 9.0 implement a variety of standard Web Services-related Java specifications and conform to a variety of standard Web Services specifications. For the full list, see Standards Supported by WebLogic Web Services.
WebLogic Server 9.0 introduces major changes in the configuration, deployment, and dynamic administration of WebLogic JMS.
For more information about these and other new features and changes in WebLogic JMS, see "New and Changed JMS Features In This Release" in Configuring and Managing WebLogic JMS.
WebLogic Server 9.0 is compliant with the new JMS 1.1 Specification for use in production, and so supports unified APIs that work for both queues and topics. See the Java JMS technology page on the Sun Web site at http://java.sun.com/products/jms/.
JMS configurations in WebLogic Server 9.0 are stored as modules, defined by an XML file that conforms to the weblogic-jmsmd.xsd schema, similar to standard J2EE modules. An administrator can create and manage JMS modules as global system resources, as modules packaged with a J2EE application (as a packaged resource), or as stand-stand-alone modules that can be made globally available. For more details, see JMS and JDBC Deployable Resource Configuration.
With modular deployment of JMS resources, you can migrate your application and the required JMS configuration from environment to environment, such as from a testing environment to a production environment, without opening an enterprise application file (such as an EAR file) or a JMS stand-alone module, and without extensive manual JMS reconfiguration.
See Understanding JMS Resource Configuration in Configuring and Managing WebLogic JMS.
The JMS Store-and-Forward feature is built on the WebLogic Store-and-Forward (SAF) service to provide highly-available JMS message production. For example, a JMS message producer connected to a local server instance can reliably forward messages to a remote JMS destination, even though that remote destination might be temporarily unavailable when the message was sent. JMS Store-and-Forward is transparent to JMS applications; therefore, JMS client code still uses the existing JMS APIs to access remote destinations.
See "Understanding the Store-and-Forward Service" in Configuring and Managing WebLogic Store-and-Forward.
New message administration enhancements greatly enhance a JMS administrator's ability to view and browse all messages, and to manipulate most messages in a running JMS server, by using the Administration Console or new public runtime APIs. These message management enhancements include message browsing (for sorting), message manipulation (such as move and delete), message import and export, transaction management, durable subscriber management, and JMS client connection management.
See Monitoring JMS Statistics and Managing Messages in Configuring and Managing WebLogic JMS.
New WebLogic JMS configuration and runtime APIs enable an administrator to pause and resume message production, message insertion (in-flight messages), and message consumption operations on a given JMS destination, or on all destinations hosted by a single JMS server. This capability enables administrative control of the JMS subsystem behavior in the event of an external resource failure.
See Troubleshooting WebLogic JMS in Configuring and Managing WebLogic JMS.
The message life cycle is an external view of the basic events that a JMS message will traverse once it is accepted by the JMS server, either through the JMS APIs or the JMS Message Management APIs. Message Life Cycle Logging provides an administrator with more information about JMS messages from the JMS server viewpoint, in particular about basic life cycle events such as message production, consumption, and removal.
See Troubleshooting WebLogic JMS in Configuring and Managing WebLogic JMS.
The JMS subsystem uses the new system-wide WebLogic Diagnostic Service for centralized debug access and logging. Debug and diagnostic information is more readily available so you can easily diagnose and fix problems.
See Understanding the WebLogic Diagnostic Service.
The Message Unit-of-Order feature goes beyond the message delivery ordering requirements in the JMS 1.1 Specification by enabling JMS message producers to group ordered messages into a single unit. The Unit-of-Order feature guarantees that all messages created from that unit are processed sequentially, in the order that they were created, by the same consumer until that consumer acknowledges them or the queue is closed. For example, if a queue has messages with many consumers, and each message has an account number as a Unit-of-Order, then two consumers will not process messages with the same account number at the same time.
See Using Message Unit-of-Order in Programming WebLogic JMS.
A new type of distributed destination, the uniform distributed destination, greatly simplifies the management and development of distributed destination applications. Using this feature, the administrator no longer needs to create or designate destination members, but relies on the system to uniformly create the necessary members on the JMS servers to which a JMS module is targeted. This feature ensures the consistent configuration of all distributed destination parameters, particularly in regard to weighting, security, persistence, paging, and quotas.
See Configuring Cluster WebLogic JMS Resources in Configuring and Managing WebLogic JMS.
The message paging feature for freeing up virtual memory during peak message load situations is always enabled on JMS servers. Additionally, administrators no longer need to create a dedicated message paging store since paged out messages can be stored in a directory on your file system. However, for the best performance you should specify that messages be paged to a directory other than the one used by the JMS server's persistent store.
See "Paging Out Messages To Free Up Memory" in Configuring and Managing WebLogic JMS.
The Weblogic JMS C API enables programs written in "C" to participate in JMS applications. This implementation of the JMS C API uses JNI in order to access a Java Virtual Machine (JVM).
See WebLogic C API in Programming WebLogic JMS.
MDB enhancements include transaction batching (processing multiple messages in a single transaction) and load balancing of distributed destinations across member destinations in different clusters or domains, regardless of whether the MDB and destination reside in the same cluster or in different clusters or domains.
See Message-Driven Bean Enhancements.
The WebLogic JMS API now provides native support for the Document Object Model (DOM) in the transmission of XML messages. This capability improves performance for implementations that already use a DOM, because those applications do not have to flatten the DOM before sending XML messages.
See Sending XML Messages in Programming WebLogic JMS.
In WebLogic Server 9.0, many changes were made to the JMS subsystem, including the removal of some classes and the deprecation of many MBeans. For a complete listing of deprecated JMS APIs, see New and Changed JMS Features In This Release in Configuring and Managing WebLogic JMS.
The new descriptor-based method of configuring JMS resources uses Java Descriptor Bean interfaces to create deployable JMS resource modules. This fundamental change necessitated the deprecation of most JMS configuration MBean interfaces, with the exception of the JMSServerMBean interface.
The descriptor-based method of configuring JMS module resources necessitated the deprecation of the JMSHelper class for locating JMS runtime and configuration JMX MBeans. This class is replaced by a new JMSModuleHelper class, with methods for locating JMS runtime MBeans, and managing JMS Module configuration entities in a given module, including the JMS Interop Module.
See the JMSModuleHelper Javadoc.
The JMSSessionPoolMBean, its associated methods on the JMSServerMBean, and the JMSConnectionConsumerMBean interfaces have been deprecated. These interfaces were used to automatically create a JMS session pool and start the JMS consumers on the server side. The ConnectionConsumer and ServerSessionPool APIs are still supported, but BEA strongly recommends using message-driven beans (MDBs), which are simpler, easier to manage, and more capable.
The new WebLogic Persistent Store necessitated the deprecation of the JMSStoreMBean, JMSFileStoreMBean, and JMSJDBCStoreMBean interfaces. This deprecation also includes any associated JMS Store methods on the JMSServerMBean interface.
See Using The WebLogic Persistent Store in Configuring WebLogic Server Environments.
WebLogic Server now fully supports the J2EE 1.5 Connector Architecture as well as resource adapters based on the J2EE 1.0 Connector Architecture. Deployment descriptors for version 1.5 are schema-based, while deployment descriptors for version 1.0 are DTD-based. Except where noted, the following sections describe new functionality for version 1.5 adapters:
The J2EE 1.5 Connector Architecture now supports resource adapters with multiple outbound connections. The outbound resource adapter enables an application to connect to an EIS system and perform work. All communication is initiated by the application. The resource adapter serves as a passive library for connecting to an EIS and executes in the context of the application threads. See Understanding Resource Adapters in Programming WebLogic Resource Adapters.
Resource adapters in previous versions supported outbound messaging. Now, Version 1.5 resource adapters can also receive transactions, including messages, from an EIS. An EIS can send a transactional context under which messages are delivered or work is performed in the form of Work Requests. A message endpoint application (a message-driven bean and possibly other J2EE components) receives inbound messages from the EIS through the resource adapter.This functionality makes the WebLogic Server proprietary InterposedTransactionManager available through a J2EE standard interface, allowing J2EE applications to fully participate in an enterprise environment controlled by an external Transaction Manager. Prior to EJB 2.1, a message-driven bean (MDB) only supported Java Message Service (JMS) messaging. See Messaging and Transaction Inflow in Programming WebLogic Resource Adapters.
Late transaction enlistment and idle connection detection are now available to 1.5 resource adapters without requiring connection proxies. See Connection Management in Programming WebLogic Resource Adapters.
The Connector specification prohibits the application server from providing access to resource adapters defined in an EAR by application components outside the EAR. However, WebLogic Integration has a continuing requirement to provide such access. The enable-access-outside-app element of the weblogic-ra.xml deployment descriptor provides a configuration parameter for explicitly enabling this access. See weblogic-ra.xml Schema in Programming WebLogic Resource Adapters.
The application server calls new start() and stop() methods as part of its deployment and undeployment actions on 1.5 resource adapters. See Packaging and Deploying Resource Adapters in Programming WebLogic Resource Adapters.
New suspend() and resume() methods enable the 1.5 resource adapter to shut down all incoming messages while allowing in-flight transactions to complete and then to resume normal operations. See Creating and Configuring Resource Adapters in Programming WebLogic Resource Adapters.
The J2EE 1.5 Connector Architecture specification advises against a resource adapter creating threads. To enable resource adapters to perform work without direct creation of threads, a self-tuning, configurable Work Manager has been added to create WorkRequests under the control of the application server. The Work Manager is configurable and allows you to manage resources. See Messaging and Transaction Inflow in Programming WebLogic Resource Adapters.
A number of new security identities can now be configured through the weblogic-ra.xml deployment descriptor. See Security in Programming WebLogic Resource Adapters.
Version 1.0 resource adapters are identified by their ConnectionFactory objects bound in the JNDI tree. Version 1.5 resource adapters are now bound in the JNDI tree as independent objects, making them available as system resources in their own right or as message sources for MDBs. See Connection Management in Programming WebLogic Resource Adapters.
All transaction and security property settings apply to all outbound connection factories. BEA has extended this functionality to allow per-connection-factory settings as well as resource adapter-scoped properties. This includes a credential map per connection factory. See Security in Programming WebLogic Resource Adapters.
You can now test either a specific outbound connection or the entire pool of outbound connections for a particular ManagedConnectionFactory. Testing the entire pool will test each connection in the pool individually. See Connection Management in Programming WebLogic Resource Adapters.
If you already know whether a connection proxy can be used in the resource adapter, you can avoid a proxy test by explicitly setting the use-connection-proxies element in the WebLogic Server 8.1 version of weblogic-ra.xml to true or false. This is applicable to resource adapters based on the J2EE 1.0 Connector Architecture, which are still supported in this release. See Connection Management in Programming WebLogic Resource Adapters.
The link-ref mechanism is a 1.0 resource adapter feature that is deprecated in the current release. The feature allows a base resource adapter to be referenced by a child resource adapter, giving the child access to the base resource adapter's classes and configuration. For 1.5 resource adapters, this mechanism is replaced by the federated application, which is a stand-alone module that can be accessed by any application. See Creating and Configuring Resource Adapters in Programming WebLogic Resource Adapters.
Foreign JNDI is an API that allows you to access objects on a remote JNDI tree without having to connect directly to the remote tree. For more information on Foreign JNDI, see Setting Up Foreign JNDI in Programming WebLogic JNDI.
The following sections describe new features and changes for JDBC in WebLogic Server 9.0:
For more information, see "New and Changed Features in WebLogic JDBC" in Configuring and Managing WebLogic JDBC.
WebLogic Server 9.0 is compliant with the JDBC 3.0 specification. See the Java JDBC technology page on the Sun Web site at http://java.sun.com/products/jdbc/ and Configuring and Managing WebLogic JDBC.
The WebLogic RowSet implementation complies with and extends the new JDBC RowSet Implementations Specification (JSR-114). See the Java JDBC technology page on the Sun Web site at http://java.sun.com/products/jdbc/.
WLCachedRowSets extends and can be used interchangeably with several standard RowSet types. It also includes methods for setting optimistic concurrency options and data synchronization options. SharedRowSet extends CachedRowSets so that additional CachedRowSets can be created for use in other threads based on data in an original CachedRowSet. SortedRowSets extends CachedRowSets so that rows in a CachedRowSet can be sorted in memory rather than depending on the database management system for sort processing. SharedRowSets and SortedRowSets increase performance by reducing the number of database round-trips required by an application.
See "Using RowSets with WebLogic Server" in Programming WebLogic JDBC.
WebLogic Server 9.0 JDBC fully supports JSR-77, which defines the J2EE Management Model. You access the J2EE Management Model to monitor resources, including the WebLogic JDBC system as a whole, JDBC drivers loaded into memory, and JDBC data sources.
See Configuring and Managing WebLogic JDBC.
JDBC configurations in WebLogic Server 9.0 are now stored in XML documents that conform to the new weblogic-jdbc.xsd schema. You create and manage JDBC resources either as system modules, similar to the way they were managed prior to version 9.0, or as application modules. JDBC application modules are a WebLogic-specific extension of J2EE modules and can be deployed either within a J2EE application or as stand-alone modules. See JMS and JDBC Deployable Resource Configuration.
In support of the new deployment model for JDBC application modules in WebLogic Server 9.0, BEA Systems provides a schema for WebLogic JDBC modules. Each JDBC system module or application module that you create must conform to the schema. IDEs and other tools can validate JDBC modules based on the schema.
For more information about WebLogic JDBC resources, see Configuring and Managing WebLogic JDBC.
Fewer JDBC resource types simplify JDBC configuration and reduce the likelihood of configuration errors. Instead of configuring a JDBC connection pool and then configuring a data source or transactional (tx) data source to point to the connection pool and bind to the JNDI tree, you configure a data source that encompasses a connection pool.
Also, MultiDataSources replace MultiPools. A MultiDataSource does not require a separate data source to bind it to the JNDI tree. If you use the Administration Console, you can configure the MultiDataSource and all encompassed data sources in one step.
See Configuring and Managing WebLogic JDBC.
The following enhancements facilitate JDBC monitoring and diagnostics.
New data source usage information is available through the Administration Console and JMX:
See Monitoring WebLogic JDBC Resources in Configuring and Managing WebLogic JDBC.
Callbacks for methods called on a JDBC driver enable you to monitor and profile JDBC driver usage, including methods being executed, exceptions thrown, and the time spent executing driver methods.
See Monitoring WebLogic JDBC Resources in Configuring and Managing WebLogic JDBC.
The JDBC subsystem uses the new system-wide WebLogic Diagnostic Service for centralized debugging access and logging.
See Understanding the WebLogic Diagnostic Service.
The Logging Last Resource (LLR) transaction option for a data source enables one non-XA resource to participate in a global transaction with improved performance and with the same ACID (atomic, consistent, isolated, and durable) guarantee as XA.
LLR transaction optimization confers these advantages:
See "Understanding the Logging Last Resource Transaction Option" in Configuring and Managing WebLogic JDBC.
Credential mapping for a JDBC data source enables WebLogic Server to set a mapped database user ID as a light-weight client ID on a database connection. This capability can reduce the need to create new connections with a specific database user ID and may enable your application to take advantage of connection pooling performance advantages.
See "Configuring Credential Mapping for a Data Source" in Configuring and Managing WebLogic JDBC.
JDBC multi data sources are supported for use in XA transactions with Oracle Real Application Clusters (RAC).
See "Using Multi Data Sources with Global Transactions" in Configuring and Managing WebLogic JDBC.
Updates to the WebLogic Type 4 JDBC drivers from DataDirect resolve important issues and include some notable enhancements. See WebLogic Type 4 JDBC Drivers for more information.
The following drivers were removed from WebLogic Server 9.0:
The following features were deprecated in WebLogic Server 9.0:
weblogic.jdbc.jts.driver—Obsolete. Use a data source to get a database connection. See Using WebLogic JDBC in an Application in Programming WebLogic JDBC.weblogic.jdbc.pool.driver—Obsolete. Use a data source to get a database connection. See Using WebLogic JDBC in an Application in Programming WebLogic JDBC.weblogic.jdbc.rmi.driver—Obsolete. Use a data source to get a database connection. See Using WebLogic JDBC in an Application in Programming WebLogic JDBC.
WebLogic Server 9.0 complies with the EJB 2.1 specification and includes many EJB usability improvements, as described in the following sections.
For more information about all these features, see Programming WebLogic Server EJBs.
The following new WebLogic Server features comply with the J2EE EJB 2.1 Specification.
The WebLogic Server EJB Timer Service enables you to schedule a notification at a particular time, at the end of an elapsed period of time, or at recurring intervals.
The following Enterprise JavaBeans query language (EJB-QL) functions are new or enhanced in WebLogic Server 9.0:
Logical message destinations can be declared in a deployment descriptor and mapped to an actual message destination, such as a JMS queue. EJBs can look up the message destination by performing a JNDI lookup with the logical message destination name.
WebLogic Server 9.0 complies with EJB 2.1 requirements related to declaring and accessing external Web Services and exposing stateless session EJBs as Web Services. These features make it easier to develop and maintain EJBs that access Web Services. Both Java and non-Java clients can access stateless session beans as Web Services.
Several enhancements make MDBs easier to use and support.
client-id for can be created for every instance of an MDB, making it easier to deploy durable MDBs to multiple servers instances in a WebLogic Server cluster.Administrators can exercise more control over how EJBs are cached and pooled. For more information on all the following features, see Programming WebLogic Server EJBs.
An administrator can configure the entity cache to release unused memory when demand increases, and to release pooled memory when demand decreases.
This feature and the configurable option described in Dynamic Entity Cache and EJB Pool to Match Demand enable customers to take advance of the response time benefits that caching and pooling offer, without continuing to consume memory as load decreases.
The EJB container can sustain a greater load before throwing a CacheFullException. In some circumstances, non-idle EJBs in cache can be passivated, so that a new request can be served.
Application developers can passivate non-idle EJB instances with the new operationsComplete method of weblogic.ejb.interfaces.EJBLocalObject This method indicates that all operations on that bean are complete for the current transaction. The container uses this information when evaluating beans for passivation.
Read-only entity EJBs can be cached at the query level and can be accessed in cache by any finder. This capability improves performance by avoiding database access.
Query caching is done implicitly by the EJB container; no application code is required. The behavior can be configured for a bean-level or application-level cache, using the max-queries-in-cache element in the entity-cache element of weblogic-ejb-jar.xml.
Container-managed persistence (CMP) entity EJBs that use optimistic concurrency have new configuration options:
Automatic retry of container-managed transactions can improve runtime performance in environments in which transactions are expected to roll back occasionally or regularly. Automatic transaction retry is supported for session and entity beans that use container-managed transaction demarcation.
In addition to EJB-QL queries, EJB developers can now specify SQL queries in weblogic-cmp-jar.xml.
Coding SQL queries is useful when the query logic cannot be expressed in EJB-QL, or if a database vendor-specific query is not supported by EJB-QL. Developers can use both EJB-QL and SQL in combination, taking advantage of EJB-QL portability benefits for most queries, and using SQL for those that cannot be accomplished with EJB-QL.
The EJB container trims trailing blanks at the end of string type values in primary key and other container-managed persistence fields. Trimming string-type values in this fashion avoids comparison errors and portability issues that might otherwise arise.
The EJB container detects symmetric and circular relationships between container-managed persistence (CMP) entities when batching and ordering database operations.
In previous versions of WebLogic Server, batch database operations on entities in symmetrical or circular relationships could result in a foreign key constraint or non-null exception.
The following sections describe new features in Web applications, JSPs, and servlets:
<context-root> element is ignored. See Creating and Configuring Web Applications in Developing Web Applications, Servlets, and JSPs for WebLogic Server.sharing-enabled attribute has been added to the session element so that Web applications can share the same session. See Using Sessions and Session Persistence in Developing Web Applications, Servlets, and JSPs for WebLogic Server.WebLogic Server now supports the Servlet 2.4 Specification from Sun Microsystems, which is downloadable at http://java.sun.com/products/servlet/download.html#specs. See the Servlet 2.4 Specification for a complete list of all of the differences between the Servlet 2.4 Specification and earlier Specifications. The following changes to WebLogic Server 9.0 support the new specification:
The <filter-dispatched-requests-enabled> element controls whether filters are applied to dispatched requests. The default value is false. Because 2.4 servlets are backward compatible with 2.3 servlets (per the 2.4 specification), when 2.3 descriptor elements are detected by WebLogic Server, the <filter-dispatched-requests-enabled> element defaults to true. See weblogic.xml Schema in Developing Web Applications, Servlets, and JSPs for WebLogic Server.
See Servlet Programming Tasks in Developing Web Applications, Servlets, and JSPs for WebLogic Server.
WEB-INF directory is not part of the public document tree of the application. No file contained in the WEB-INF directory can be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext, and may be exposed using the RequestDispatcher calls. See Creating and Configuring Web Applications in Developing Web Applications, Servlets, and JSPs for WebLogic Server.ServletRequestListener and ServletRequestAttributeListener) can manage state across the life cycle of servlet requests and the methods invoked when the request events occur. See Application Events and Event Listener Classes in Developing Web Applications, Servlets, and JSPs for WebLogic Server.WebLogic Server now supports the JSP 2.0 Specification from Sun Microsystems. The following changes to WebLogic Server 9.0 support the new specification:
SimpleTag tag handler API for JSPs—Provides a much simpler invocation protocol than do classic tag handlers. See Implementing the Tag Handler in Programming WebLogic JSP Tag Extensions.The following Web Application features are deprecated in this release of WebLogic Server:
javax.servlet.SingleThreadModel instance pools. WebLogic Server still supports SingleThreadModel; however, its use is not recommended. See weblogic.xml Schema in Developing Web Applications, Servlets, and JSPs for WebLogic Server.<redirect-content-type> element is obsolete in this release. See weblogic.xml Schema in Developing Web Applications, Servlets, and JSPs for WebLogic Server.