|
|
Welcome to WebLogic Server. The following sections describe new and changed functionality in this WebLogic Server (WLS) release.
This release of WebLogic Server introduces changes to the Administration Console, as described in the following sections:
The Console has been redesigned with new colors, borders, buttons, and such.
The following options have been added for configuring Console behavior.
The Administration Console Change Center provides a way to lock a domain configuration so you can make changes to the configuration while preventing other accounts from making changes during your edit session.
In previous releases, the Change Center domain locking feature was always enabled. It is now possible to enable or disable the feature in development domains. It is disabled by default when you create a new development domain.
See Enable and disable the domain configuration lock in Administration Console Online Help.
On the Configuration: General page for each domain, you can specify whether to deploy internal applications such as the Administration Console, UDDI, and the UDDI Explorer on demand (upon first access) instead of during server startup.
See Domains: Configuration: General in Administration Console Online Help.
By default, you are prompted for operation confirmations in a production domain but not in a development domain. A new option on the Preferences: User Preferences page lets you enable confirmation prompts in development domains.
See Preferences: User Preferences in Administration Console Online Help.
You can use the new search feature in the banner toolbar region to find any WebLogic Server Configuration MBeans that contain the string you specified in their name.
See Search the configuration in Administration Console Online Help.
The following enhancements improve the performance, accessibility, and operational consistency of the Console.
The Administration Console has been updated with a number of new and changed pages. These are described in the following sections. For more information about these changes, see Administration Console Online Help.
WebLogic Server now supports the use of SAML2 security providers. The Console has been updated to provide new pages for SAML2 identity asserters and credential mappers, and new server-specific security configuration pages.
New pages are also included to configure the new file-based and RDBMS security store features of WebLogic Server.
All pages that include an encrypted password field now also include confirmation fields for those passwords.
Console pages that export security configuration information to external files now check for the existence of those files before overwriting.
Credential mappings may now be edited from within the Console.
The Summary of Servers page now contains two tabs: Configuration and Control.
WebLogic Server now supports additional capabilities for automatically migrating failed servers and services from one server to another. The Console pages for configuring Migratable Targets have been updated to reflect those changes.
New Console pages provide controls for configuring Reliable Messaging settings for Web Services.
A Console Extension Preference page provides links for displaying information about Console extensions and provides options for enabling and disabling extensions and for displaying Console extension points. See Manage Console extensions and Display Console Extension Point Labels in Administration Console Online Help.
The Administration Console now includes the ability to inspect Spring applications. This feature is packaged as a Console extension named spring-console.jar. You must enable this extension in the Console, as described in
Manage Console extensions in Administration Console Online Help. See also
Spring Applications Reference in Developing Applications with WebLogic Server.
In this release, portions of the Administration Console have been refactored as Console extensions:
The following sections describe changes of interest to Console extension developers.
The Administration Console uses a new Portal look and feel, called wlsconsole, that is based on the WebLogic Portal 10.0 look and feel. The following list describes the main differences from WebLogic Portal 10.0:
wlp-bighorn- to wlsc-.singlelevelmenu.jsp and abstractmenu.jsp support extra Console functionality in tabs.book.jsp and window.jsp contain conditional logic to generate extra markup needed for the gray round corner frame style.twocollayout.jsp is a two-column layout where one column is fixed width and the other is dynamic. nolayout.jsp is a layout that adds no extra markup.
Sample look and feel files are now packaged with WebLogic Server. You no longer have to copy the look and feel files from the MedRec sample application, as in previous releases. The new files are in the $WL_HOME/server/lib/console-ext/templates directory. The files are:
Use this ant script to create the initial set of look and feel files for your extensions. It copies the look and feel files from laftemplate.zip (see below) into a new directory and renames components, such as skeletons and skins, to match the name of the extension.
This file contains the initial set of look and feel files that build-new-laf.xml (see above) expands. You should not open or use this file directly.
console-html.tld) have been improved to remove hard coded styles and produce valid HTML.framework\skins\extension_name\css and framework\skins\wlsconsole\css folders. The CSS files are:LoginError.jsp. It now forwards to LoginForm.jsp.skeletonUri attributes in your portal files. Instead, use presentationClass and presentationId attributes, and specify styles with CSS.presentationClass="wlsc-frame" attribute to top level books or portlets that have a title bar.
The Console now supports an additional metadata tag, helpurlpattern, which can be used to specify how help will be sourced.
You can provide create online help for an extension, merge it into the main Administration Console help, and rebrand the Console help.
The following features are new to WebLogic Core Server in this release:
This release supports Sun JDK 1.6, which delivers superior performance compared to previous versions and leverages JDK6 delivered features, such as:
This release includes the following enhancements to the WebLogic JarBuilder tool:
wljarbuilder.jar, which is used to create a consolidated wlfullclient.jar for client applications, no longer includes the version number in the file name. The wljarbuilder.jar has also been changed to a manifest-only JAR that points to the latest jarbuilder module. For more information, see
Using the WebLogic Jar Builder Tool in Programming Stand-alone Clients.
The following features are new to WebLogic deployment in this release:
With FastSwap Deployment in WLS, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy and then navigate back to wherever you were in the Web page flow. Instead, you can make your changes, auto compile, and then see the effects immediately.
FastSwap is only supported when WLS is running in development mode. It is automatically disabled in production mode. See Using FastSwap Deployment to Minimize Redeployment in Deploying Applications to WebLogic Server.
There are many internal applications that are deployed during startup. These internal applications consume memory and require CPU time during deployment. This contributes to the WebLogic Server startup time and base memory footprint. Since many of these internal applications are not needed by every user, WebLogic Server has been modified to wait and deploy these applications on the first access (on-demand) instead of always deploying them during server startup. This reduces startup time and memory footprint.
See On-demand Deployment of Internal Applications in Deploying Applications to WebLogic Server.
This feature lets you place application-specific files to be overridden into a new optional subdirectory (named AppFileOverrides) in the existing plan directory structure. The presence or absence of this new optional subdirectory controls whether file overrides are enabled for the deployment. If this subdirectory is present, an internal ClassFinder is added to the front of the application and module ClassLoaders for the deployment. As a result, the file override hierarchy rules follow the existing ClassLoader and resource loading rules and behaviors for applications.
| Note: | This mechanism is only for overriding resources and does not override classes. |
See Generic File Loading Overrides in Deploying Applications to WebLogic Server.
The WebLogic Diagnostics Framework (WLDF) has new features.
This section describes Harvester capabilities enhancements.
The WLDF Harvester now supports collecting and archiving data from MBean attributes that are nested bean structures or collections. This lets you collect data from nested complex data types or collections, such as lists, arrays, and maps. See Specifying Complex and Nested Harvester Attributes in Configuring and Using the WebLogic Diagnostic Framework.
In prior releases, the Harvester instance specification had to be in the form of an ObjectName. This requirement could be cumbersome and error prone since the ObjectNames of WebLogic Server MBeans are complex.
To alleviate this, the WLDF now allows:
See Using Wildcards in Harvester Instance Names in Configuring and Using the WebLogic Diagnostic Framework.
The Harvester configuration now supports a namespace attribute, which provides the ability to harvest MBeans that reside in the DomainRuntime MBeanServer that is running on the Administrator Server. See
Harvesting from the DomainRuntime MBeanServer in Configuring and Using the WebLogic Diagnostic Framework.
This section describes Watch capabilities enhancements.
Similar to the support for nested complex attributes (such as a collection, an array type, or an Object with nested intrinsic attribute types) in the Harvester configuration, the Harvester Watch rules also fully support the complex drill-down syntax of the Harvester. While configuring instance based rules, object names for instances can be specified as patterns. See Specifying Complex Attributes in Harvester Watch Rules in Configuring and Using the WebLogic Diagnostic Framework.
The wildcard support that is available for Harvester configuration is also being supported for the Watch rule specifications that have an instance name. See Using Wildcards in Watch Rule Instance Names in Configuring and Using the WebLogic Diagnostic Framework.
With the integration of the DomainRuntime MBeanServer with the Harvester, it is now possible to reference run-time metrics from a Harvester Watch rule. In order to do so, the variable syntax for a Harvester Watch rule now allows the namespace specification, where the metric is registered. See
Creating Harvester Watch Rule Expressions in Configuring and Using the WebLogic Diagnostic Framework.
EJB 3.0 enhancements include new and changed features, particularly in the area of Java Persistence API (JPA), as described in the following sections:
The kodo.ManagementConfiguration configuration property has been replaced with the following three configuration properties for configuring profiling, JMX, and the execution context name provider, respectively:
For more information about the new configuration properties, see 12.1. Configuration in the Kodo Developer Guide.
The Kodo persistence-configuration.xml descriptor file is now parsed when running in a non-WLS environment. For more information about using the persistence-configuration.xml descriptor file, see
Using Oracle Kodo with WebLogic Server in Programming WebLogic Enterprise JavaBeans, Version 3.0.
In order to provide optimal runtime performance, flexible lazy loading, and efficient, immediate dirty tracking, Kodo uses a class enhancer to add code to your persistent classes after you have written and compiled them. The enhancer post-processes the byte code generated by your Java compiler, adding the necessary fields and methods to implement the required persistence features. In WebLogic Server, this enhancement can be performed at compile time, using a standalone enhancer, or at run time when the classes are loaded. Running this process as a compile-time process can help to reduce deployment time and to catch any possible errors earlier in the compile-test cycle.
Since WebLogic Server 10.0, the kodoc command was used to run the Kodo class enhancer. In this release, the kodoc functionality is now integrated into appc enabling application classes to be run through the Kodo class enhancer when running appc. For more information, see
appc Reference in Programming WebLogic Enterprise JavaBeans.
This release of WebLogic Server provides a set of MBeans for monitoring Kodo runtime status. These MBeans are registered automatically in the WebLogic Server Runtime MBean server.
| Note: | Kodo already provides a set of JMX MBeans, including MBeans that provide some of the same information made available by the new MBeans. The new MBeans have been revised to align with WebLogic Server MBean standards. |
The following table describes the new WebLogic Kodo MBeans.
The Session and message-driven bean implementation in WebLogic Server includes a number of proprietary specification extensions that you configure using the weblogic-ejb-jar.xml. In this release, a subset of these extensions can be configured using annotations.
The following WebLogic Kodo annotations are available in the weblogic.javaee package. For more information, see
WebLogic Kodo Annotations in Programming WebLogic Enterprise JavaBeans, Version 3.0.
The following Kodo properties can be dynamically updated, without restarting WebLogic Server:
Changes made to the values of these properties are saved in the plan.xml file can be activated without redeploying the application that contains the respective persistence units.
These settings can be modified using the Administration Console, WLST or the weblogic.Deployer command. For more information, see
Overview of WebLogic Server System Administration in Introduction to Oracle WebLogic Server.
The Guardian diagnostic tool is included with this release of WebLogic Server. Guardian is not enabled by default. You can enable it via the GuardianEnabled attribute of the DomainMBean, using WLST or the Administration Console. To enable Guardian from the Administration Console:
Configuration, then select the Enable Oracle Guardian Agent option.For more information about Guardian, see the Guardian User Guide.
The following enhancements have been made to the WebLogic Server installer:
The WebLogic Server installer includes enhancements that enable you to select only the software components you need, thus reducing the disk and runtime footprint.
See Overview in Getting Started With Installation.
The Net installer involves initially downloading a small piece of software of software, selecting installation options, and then downloading and installing only the components you select. The Net installer eliminates the need to download a large single executable binaries file before actually installing the product.
See Net Installer in Getting Started With Installation.
In this release of WebLogic Server, additional progress is achieved towards delivering a modular server that allows users to choose which components of WebLogic Server they use. Specifically, this release allows users to choose whether the EJB, JMS and J2CA services are started when WebLogic Server is started. The benefit of excluding some services is reduced memory footprint and reduced startup time.
The following features are new to WebLogic JDBC in this release of WebLogic Server.
This release of WebLogic Server is compliant with the JDBC 4.0 specification, with the following enhancements and exceptions:
getSource and setResult APIs on the client side.For more information, see the Java JDBC technology page on the Sun Web site at http://java.sun.com/javase/technologies/database/.
The WebLogic Type 4 JDBC drivers included with WebLogic Server are provided from DataDirect. In this release, the drivers have been updated to DataDirect Version 3.7. The following sections describe new features and changes for the WebLogic Server Type 4 JDBC Drivers:
ConvertNull connection option to control how data conversions are handled for null values.QueryTimeout connection option for setting a default query timeout.For more information, refer to the documentation for each driver.
EncryptionMethod connection option for configuring data encryption across the network.For detailed information on these changes, see The DB2 Driver in Type 4 JDBC Drivers.
For detailed information on these changes, see The Informix Driver in Type 4 JDBC Drivers.
| Note: | The Oracle Type 4 JDBC driver has been deprecated as of this release of WebLogic Server. It will be removed in the next release of WebLogic Server. Instead of this deprecated driver, use the Oracle Thin Driver that is also provided with WebLogic Server. For details about the Oracle Thin Driver, see Using Third-Party JDBC Drivers with WebLogic Server in Configuring and Managing WebLogic JDBC. |
EncryptionMethod connection option for configuring data encryption across the network.ValidateServerCertificate and HostNameInCertificate connection options for configuring certificate validation behavior.TrustStore and TrustStorePassword connection options for configuring truststore information.KeyStore, KeyStorePassword, and KeyPassword connection options for configuring keystore information for SSL client authentication.SysLoginRole connection option for configuring whether the user is logged on the database with the Oracle system privilege SYSDBA or the Oracle system privilege SYSOPER.For detailed information on these changes, see The Oracle Driver in Type 4 JDBC Drivers.
EncryptionMethod connection option for configuring data encryption across the network.TrustStore and TrustStorePassword connection options for configuring truststore information.DescribeParameters connection option to control whether the driver will attempt to determine, at execute time, how to send String parameters to the server based on the database data type.DatabaseName connection property.LongDataCacheSize connection property controls whether the driver caches long data (images, pictures, long text, or binary data) in result sets.For detailed information on these changes, see The MS SQL Server Driver in Type 4 JDBC Drivers.
LongDataCacheSize connection option controls whether the driver caches long data (images, pictures, long text, or binary data) in results sets.PacketSize connection option for configuring the database protocol packet size.DatabaseName connection property.For detailed information on these changes, see The Sybase Driver in Type 4 JDBC Drivers.
This release includes support for Oracle 11g and 11g RAC (Real Application Clusters). Support for 11g RAC continues to rely on the well-proven integration architecture using Multi-Data Sources for XA with load balancing.
See Using WebLogic Server with Oracle RAC in Configuring and Managing WebLogic JDBC.
Logging in WebLogic Server now provides finer control of Logging Severity, down to the level of the logging source that is generating the message. This is provided via a set of Severities that are defined in the weblogic.logging.Severitiies class.
The LogMBean interface offers two new attributes:
See Specifying Severity Level for Loggers in Configuring Log Files and Filtering Log Messages.
This release of WebLogic Server includes the following improvements in WebLogic Server JMS:
The WebLogic Server migration framework allows an administrator to specify a migratable target for JMS-related services, such as JMS servers and SAF agents. The WebLogic administrator can also configure migratable services so that will be automatically migrated from a failed server based on WebLogic Server health monitoring capabilities. This improves the availability of migratable JMS-related services in a cluster because those services can be quickly restarted on a redundant server should the host server fail.
See Roadmap for Configuring Automatic Migration of JMS-Related Services in Using Clusters.
This release of WebLogic Server includes a WebLogic JMS .NET client, which is a fully-managed .NET runtime library and API that enables programmers to create .NET client applications, written in C#, that can access WebLogic JMS applications and resources.
See Use the WebLogic JMS Client for Microsoft .NET.
This release of WebLogic Server provides Asynchronous HTTP Session Replication (AsyncRep) to improve cluster performance.
AsyncRep gives you the option to choose asynchronous session replication to the secondary server. It also provides the ability to throttle the maximum size of the queue that batches up session objects before the batched replication takes place.
AsyncRep is used to specify asynchronous replication of data between a primary server and a secondary server. In addition, this option enables asynchronous replication of data between a primary server and a remote secondary server located in a different cluster according to a cluster topology of MAN.
See Asynchronous HTTP Session Replication in Performance and Tuning.
The following features are new to WebLogic security in this release:
This release of WebLogic Server includes broad support for SAML 2.0, including support for the SAML 2.0 Web Single Sign-On (SSO) profile and the Web Services Security (WS-Security) SAML Token profile 1.1.
The SAML 2.0 Web SSO profile is part of the core set of SAML 2.0 standards, and specifies how SAML 2.0 assertions and protocols should be used to provide browser-based single sign-on between and among Identity Provider (IdP) sites and Service Provider (SP) sites.
The SAML Token profile is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for Web Services security. This release of WebLogic Server supports SAML Token Profile 1.1, including support for SAML 2.0 and SAML 1.1 assertions. SAML Token Profile 1.1 is backwards compatible with SAML Token Profile 1.0.
Support for SAML 2.0 is provided by several different components areas, including:
The new SAML 2.0 Credential Mapping provider and SAML 2.0 Identity Assertion provider generate and consume, respectively, SAML 2.0 assertions.
At least one of the providers must be configured in order to use of SAML 2.0 in this release of WebLogic Server.
| Note: | For some uses of SAML 2.0, the SAML authentication provider must also be configured. The SAML authentication provider enables “virtual user” functionality for both the SAML 2.0 and SAML 1.1 identity asserters. |
This release of WebLogic Server can be configured to act as a SAML 2.0 Identity Provider, Service Provider, or both. When configuring a WebLogic Server instance as an Identity Provider, you must configure the SAML 2.0 Credential Mapper so that the Identity Provider can generate assertions. When configuring a WebLogic Server instance as a Service Provider, the SAML 2.0 Identity Assertion provider must be configured so that the Service Provider can consume assertions.
SAML 2.0 single sign-on services are configured on a per-server basis. To enable SAML 2.0 single sign-on services in two or more WebLogic Server instances in a domain, or among the Managed Servers in a cluster, you must do the following:
For more information about configuring SAML 2.0 single sign-on service, see Configuring Single Sign-On with Web Browsers and HTTP Clients in Securing WebLogic Server.
This release of WebLogic Server Web Services now supports SAML Token Profile 1.1. This feature includes support for SAML 2.0 and SAML 1.1 assertions, and is backwards compatible with SAML Token Profile 1.0 SAML tokens are configured for a Web Service through use of the appropriate WS-SecurityPolicy assertions.
| Note: | SAML Token Profile 1.1 is supported only through WS-SecurityPolicy. The earlier “WLS 9.2 Security Policy” supports SAML Token Profile 1.0/SAML 1.1 only. |
When using SAML Token Profile, the appropriate SAML security providers must be configured (either the SAML 2.0 or SAML 1.1 Credential Mapping or IdentityAssertion providers), depending on the desired SAML version(s) and assertion usage. For more information, see Configuring Message-Level Security in Securing WebLogic Web Services.
This release of WebLogic Server provides the option of using an external RDBMS as a datastore that is used by the following security providers:
The use of the RDBMS security store is required to use SAML 2.0 services in two or more WebLogic Server instances in a domain.
The following RDBMS systems can be used for the RDBMS security store:
The Configuration Wizard has been modified to allow you to create the RDBMS security store at the time you create a domain. When you boot the domain, you may set additional configuration options for the RDBMS security store from the WebLogic Administration Console.
WebLogic Server provides a set of SQL scripts for each supported RDBMS system that must be run prior to booting the domain. These scripts create the tables in the datastore that are used by the security providers.
If you are configuring SAML 2.0 services in two or more WebLogic Server instances in a domain, such as in a cluster, you must have a domain in which the RDBMS security store and a JMS topic have been configured. This enables the security information managed by the SAML 2.0 security providers to be synchronized among each server instance.
For more information about the RDBMS security store, see Managing the RDBMS Security Store in Securing WebLogic Server.
WebLogic Server now includes a Password Validation provider, which can be configured with one of the following authentication providers to enforce a set of configurable password composition rules:
When a password is created or modified using an authentication provider that has been configured with the Password Validation provider, the password is automatically validated against a set of composition rules. The password composition rules are configurable and can govern the minimum length of passwords, minimum number of alphabetic or numeric characters that are required, the number of non-alphanumeric characters that are required, and more.
The Password Validation provider is configured via the WebLogic Scripting Tool (WLST). For more information, see Configuring the Password Validation Provider in Securing WebLogic Server.
This section describes Spring integration improvements for this release of WebLogic Server.
The Java EE specification added Dependency Injection (DI) to Web and EJB container, and interceptors (a form of AOP) to the EJB container. The Spring container is the leader in DI and AOP. WebLogic Server is using Pitchfork to bridge with Spring to provide DI and interceptors to the WLS Java EE container. This integration not only satisfies the standard specification requirement, it also creates the possibility for extension to the JavaEE5 specification as the Spring framework provides a richer set of features in terms of DI and AOP.
WLS takes advantage of these integration features, providing the extension to the standard JavaEE5 DI and AOP. This extension provides DI and AOP to an EJB instance and Web components that include the servlet listener and filter. In order to maintain server compliance, the standard out-of-box WebLogic Server installation only provides the standard JavaEE5 DI and AOP.
The Spring console for this release of WebLogic Server provides useful management functionality for Spring Beans that are deployed to a WebLogic Server instance. The Spring console is implemented as an extension to the standard WebLogic Server Administration Console.
The WLS security system supports and extends Java EE security while providing a rich set of security providers that you can customize to integrate with different security databases or security policies. Besides using standard Java EE security, application programmers can use a wide array of proprietary extensions that allow an application to tightly integrate with the security system. WLS packages several security provider offerings.
The Spring security (acegi) provides security to a Spring application while providing a rich set of security providers.
For a blended J2EE and Spring application, rather than require authentication with both security frameworks, WLS and Spring security will work together. WLS security handles the authentication, and converts WLS principals to Spring GrantedAuthority through a mapper class. Once authenticated by WLS security, a user is authenticated for Spring security. You can then decide how to secure the objects in the application.
The following features and changes are new to Web applications, servlets and JSPs in this release.
An HTTP Publish-Subscribe Server (also called pub-sub server) is a channels-based publish/subscribe mechanism for Web clients to send and receive asynchronous messages over HTTP. One of the principal uses of the pub-sub server is to build event-driven or push-based Web 2.0 internet applications that are collaborative and capable of supporting multiple listening and publishing channels with thousands of users.
For more information, see Using the HTTP Publish-Subscribe Server in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
The following sections describe debugging support enhancements that have been made in the servlet container for this release.
In cases where access logging is not required, you can improve server performance by disabling access logging. A new optional property access-logging-disabled has been introduced into container-descriptor in weblogic.xml to indicate if access logging is disabled.
A request flag named wl_debug_session as well as a same-named session attribute have been introduced to log the changes of the current request in the current session. If either flag is used, the container logs the modifications of the underlying session into the server log.
The WLS servlet container provides more detailed log messages during request handling to better describe each milestone in a request flow. No additional configuration changes are required other than enabling the HttpDebug logger. You can then find the footprint of a request handle in the server log.
For more information about these debugging enhancements, see Debugging Servlet Containers in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
The following sections provide information on application container features for this release.
Prior to this release, the namespace included version information. The version-independent namespace in this release of WebLogic Server makes WLS-specific deployment descriptors easier to use and reduces the workload of schema upgrades. The namespace has been broken into multiple namespaces, one per descriptor. The version has also been removed from the namespaces to make them more stable. A version attribute has also been introduced for the root element of each descriptor.
For a listing of WLS deployment descriptors and their corresponding schemas, see XML Deployment Descriptors in Developing Applications With WebLogic Server.
Additional descriptors are supported in AppMerge for the deployment view in this release of WebLogic Server.
The path of the external diagnostics descriptors is defined in the plan.xml file as an external entry. This feature supports the deployment view and deployment of an application or a module, detecting the presence of an external diagnostic descriptor if the descriptor is declared in the plan.
WebLogic-specific descriptor Bean files and schema files are now included in com.bea.core.desciptor.wl_VERSION.jar and com.bea.core.descriptor.wl.binding_VERSION.jar. These JAR files can be found in the modules directory.
The following container performance-related enhancements have been introduced in this release:
The require-admin-trafffic element can determine whether traffic should always go through the administration channel or only when the Web application is in administrative mode.
The access-logging-disabled element can eliminate access logging of the underlying Web application, which can improve server throughput by reducing the logging overhead.
The compress-html-template element can compress the HTML in the JSP template blocks to improve runtime performance.
The optimize-java-expression element can optimize Java expressions to improve runtime performance.
For more information about these new elements, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
File-based HTTP session performance has been dramatically improved by a factor of 10 in this release of WebLogic Server.
The docHome parameter for FileServlet, which was deprecated in release 9.2, has been removed in this release of WebLogic Server. Use virtual directories as an alternative.
Web Services include new and changed features, as described in the following sections:
WebLogic Web Services support updated versions of the following standards:
For more information, see Standards Supported by WebLogic Web Services in Introducing WebLogic Web Services.
Java API for XML-based Web Services (JAX-WS) 2.1 is supported in this release, adding the following features to those found in JAX-WS 2.0:
The WebLogic Server implementation of JAX-WS is based on the JAX-WS Reference Implementation (RI), Version 2.1.4, and includes enhancements to the tool layer to simplify the building and deployment of JAX-WS services and to ease the migration from JAX-RPC to JAX-WS. The following features and enhancements are available from the JAX-WS RI 2.1.4:
As with WebLogic Server 10.0, developers may begin development with either a Java source file or WSDL file. The WebLogic Server Ant tasks <jwsc> and <clientgen> automate the generation of portable data binding classes, creation of deployment descriptors, and packaging.
For more information about using JAX-WS, see:
Web Services Reliable Messaging (WS-ReliableMessaging) 1.1 is supported in this release. This version includes several protocol-level enhancements, but does not significantly impact how clients interact with reliable services using WebLogic Service facilities (for example, stubs, WsrmUtils).
To use the WS-ReliableMessaging 1.1 protocol in your Web Services, attach a WS-ReliableMessaging 1.1 policy to your reliable JWS using the @Policy annotation. (The process is similar to the process of attaching a WS-ReliableMessaging 1.0 reliable service.). For your convenience, there are several pre-packaged policy files, such as the DefaultReliability1.1.xml policy file, that are provided to help you get started.
The following changes have been made to the WS-ReliableMessaging 1.1 protocol:
WsrmUtils.setLastMessage and WsrmUtils.sendEmptyLastMessage. For more information about WS-ReliableMessaging, see Using Web Services Reliable Messaging in Programming Advanced Features of WebLogic Web Services Using JAX-RPC.
You can configure multiple policy alternatives—also referred to as smart policy alternatives—for a single Web Service by creating a custom policy file. At run time, WebLogic Server selects which of the configured policies to apply. It excludes policies that are not supported or have conflicting assertions and selects the appropriate policy, based on your configured preferences, to verify incoming messages and build the response messages.
For more information about smart policy selection, see:
WebLogic Server now supports version-independent policy. That is, the WS-Policy or WS-SecurityPolicy policy can be based on either of the supported namespaces, and can come from different sources using different namespaces. At run time, the merged policy file then contains two or more different namespaces. See Version-Independent Policy Supported in Securing WebLogic Web Services.
WebLogic Server now supports the Optional WS-Policy assertion. The following security policy assertions are now supported by the Optional policy assertion:
See Using the Optional Policy Assertion in Securing WebLogic Web Services for more information.
WebLogic Server supports the element-level assertions defined in WS-SecurityPolicy 1.2. These assertions allow you to apply a signature or encryption to selected elements within the SOAP request or response message, enabling you to target only the specific data in the message that requires security and thereby reduce the computational requirements.
See Configuring Element-Level Security in Securing WebLogic Web Services for more information.
The SAML Token Profile 1.1 is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for Web Services security. WebLogic Server supports SAML Token Profile 1.1, including support for SAML 2.0 and SAML 1.1 assertions. SAML Token Profile 1.1 is backwards compatible with SAML Token Profile 1.0.
See Using Security Assertion Markup Language (SAML) Tokens for Identity in Securing WebLogic Web Services for more information.
WebLogic Server now supports XML catalogs with JAX-WS Web Services. An XML catalog enables your application to reference imported XML resources, such as WSDLs and XSDs, from a source that is different from that which is part of the description of the Web Service. Redirecting the XML resources in this way may be required to improve performance or to ensure your application runs properly in your local environment.
For example, a WSDL may be accessible during client generation, but may no longer be accessible when the client is run. You may need to reference a resource that is local to or bundled with your application rather than a resource that is available over the network. Using an XML catalog file, you can specify the location of the WSDL that will be used by the Web Service at run time.
For more information about using XML catalogs, see Using XML Catalogs in Programming Advanced Features of WebLogic Web Services Using JAX-WS.
To support XML Catalog, a new Ant task, wsdlget, is supported that enables you to download a WSDL and its imported XML targets to the local directory, such as XSD and WSDL files. For more information, see
wsdlget in WebLogic Web Services Reference.
In conjunction with Microsoft, Oracle has performed interoperability testing to ensure that the Web Services created using WebLogic Server can access and consume Web Services created using Microsoft Windows Communication Foundation (WCF)/ .NET 3.0 Framework and vice versa. For complete details, see Interoperability With Microsoft WCF/.NET in Introducing WebLogic Web Services.
The WebLogic Web Services documentation set has been reorganized, as summarized in the following table.
A listApplications() command, which lists all applications that are currently deployed to the domain, has been added to WLST. For more information, see
Deployment Commands in WebLogic Scripting Tool.
This release of WebLogic Tuxedo Connector includes:
For more information, see Oracle WebLogic Tuxedo Connector Administration in the WebLogic Tuxedo Connector Administration Guide.
With this release of WebLogic Server, the full Workshop IDE is available.
The command line tool EarInit, documented in the WebLogic Server Command Reference, has been deprecated in this release of WebLogic Server. As a result, you should no longer:
The Oracle Type 4 JDBC driver has been deprecated in this release of WebLogic Server. It will be removed in the next release of WebLogic Server. Instead of this deprecated driver, you should use the Oracle Thin Driver that is also provided with WebLogic Server. For details about the Oracle Thin Driver, see Using Third-Party JDBC Drivers with WebLogic Server in Configuring and Managing WebLogic JDBC.
Internal fields and methods in the following classes have been deprecated in this release of WebLogic Server, and are no longer documented.
See the following table for a complete list.
OpenJPA now has a set of APIs for which compatibility is guaranteed. These are the public interfaces and annotations in the org.apache.openjpa.persistence and org.apache.openjpa.persistence.jdbc packages. To ensure this compatibility, the return type for some method signatures on these interfaces were changed in non-backward compatible ways (see Table 1-4). Other methods and fields were deprecated in OpenJPA 1.0, making it likely that they will be removed in a future release of OpenJPA (see Table 1-5). Therefore, their use cannot be relied on.
| Note: | Only the OpenJPA interfaces and classes marked @published have compatibility guarantees. The OpenJPA project strives to maintain compatibility for the SPI interfaces, but does not provide any guarantees on them. Additionally, classes and interfaces navigable from the SPI interfaces may change in the future.
|
||||||||||||||||||||||||||||||||||||||
In this release of WebLogic Server, the org.apache.openjpa.persistence.OpenJPAEntityManager interface extends EntityTransaction. This relationship is deprecated; in future releases, OpenJPAEntityManager will not extend EntityTransaction.
The following provides an example of how this might impact your code:
OpenJPAEntityManager em = ...
EntityTransaction t = em;
OpenJPAEntityManager em = ...;
EntityTransaction t = em;
Apache Beehive has been deprecated as of WebLogic Server Version 10.3. Oracle intends to remove Apache Beehive APIs in a future WebLogic Server Version release. In preparation, we recommend that you migrate your Beehive applications and infrastructure to other frameworks such as Oracle's ADF or Java Server Faces at your earliest convenience. Note, Beehive will still be available and supported for use within WebLogic Integration and WebLogic Portal.
This release of WebLogic Server supports the following standards.
|