|
|
|
|
|
|
| | | |
WebLogic Server 6.1 Features and Changes
The following sections describe changes and features in WebLogic Server 6.1.
The current release is WebLogic Server 6.1 Service Pack 6. Each Service Pack contains the changes and corrections introduced in prior Service Packs.
The following sections highlight the key changes in each WebLogic Server 6.1 Service Pack.
For information about current known problems in WebLogic Server 6.1, see Notes and Problems.
WebLogic Server 6.1 Service Pack 7
These sections describe key changes in WebLogic Server 6.1 SP07.
Oracle 10g Thin Driver Bundled with WebLogic Server
In WebLogic Server 6.1 Service Pack 7, the Oracle 10g Thin driver is installed with WebLogic Server in the WL_HOME\lib\oracle\10g folder. BEA provides the 10g driver so that you can optionally use it with WebLogic Server. However, the Oracle 9.2.0 Thin driver remains the default version of the driver. To use the Oracle10g Thin driver, you must add the driver classes to your CLASSPATH in front of weblogic.jar. See "Using the Oracle 10g Thin Driver" in Programming WebLogic JDBC for more information.
Note: Oracle removed some methods and classes from the 10g Thin driver that were in previous versions of the driver. If you use any of the extension methods that were removed, you will see errors in your application.
WebLogic Server 6.1 Service Pack 6
These sections describe bug fixes and key changes in WebLogic Server 6.1 SP06.
Changes in EJB
A field optimization was implemented for EJB 1.1 CMP beans, so that fields that are updated but whose values are not changed are not written to back to the database. The optimization applies to primitive and immutable fields only.
Changes in System Administration
You must provide user credentials for any weblogic.Admin command that connects to a WebLogic Server instance. A new command, STOREUSERCONFIG, encrypts and stores user credentials, so that you do not have to pass unencrypted credentials on the command line or in scripts. For more information, see STOREUSERCONFIG in WebLogic Server Administration Guide.
WebLogic Server 6.1 Service Pack 5
These sections describe bug fixes and key changes in WebLogic Server 6.1 SP05.
WebLogic Server 6.1 Service Pack 4
These sections describe bug fixes and key changes in WebLogic Server 6.1 SP04:
Changes in System Administration
This section lists key system administration changes in WebLogic Server 6.1 SP04.
Change in Behavior of -delay Argument for beasvc.exe
The behavior and usage of the -delay argument for beasvc.exe, the WebLogic Server Windows service program, is changed in WebLogic Server 6.1 SP04.
Previously, the -delay argument was applied when invoking beasvc.exe for Managed Server. When the Windows Service Control Manager (SCM) started a Managed Server as a service, it waited for the period (in milliseconds) specified with the -delay argument, set the service status to STARTED, and started the service.
In WebLogic Server 6.1 SP04, the -delay argument is applied at the Administration Server level, rather than for each Managed Server. Use the -delay argument when invoking beasvc.exe for the Administration Server for the domain. The argument affects all services that depend on the Administration Servers, including Managed Servers in the domain.
There are also changes in the effect that -delay has on service status and startup. In WebLogic Server 6.1 SP04, the Windows Service Control Manager (SCM) starts the Managed Server immediately, sets the service status to SERVER_START_PENDING, and after the specified delay has elapsed, sets the service status to STARTED.
New Parameter for Forced Application Update
A new startup option for Administration Servers, -Dweblogic.management.forceApplicationCopy, forces Managed Servers to obtain the latest version of deployed applications at startup. The effect of the startup option is described in Forcing Application Update at Startup. Default Application Update Process describes how Managed Servers obtain updates when -Dweblogic.management.forceApplicationCopy is false, as it is by default.
Forcing Application Update at Startup
The parameter -Dweblogic.management.forceApplicationCopy can be specified as a startup option for an Administration Server, either on the command line or in a startup script. If an Administration Server is started with -Dweblogic.management.forceApplicationCopy set to true, when a Managed Server in the domain starts up, the applications deployed to that Managed Server are copied from the Administration Server to the Managed Server.
Default Application Update Process
If an Administration Server is not started with -Dweblogic.management.forceApplicationCopy set to true, an application is only copied to a Managed Server at startup if both these conditions are true:
The Administration Server maintains a StagedTargets list that specifies which Managed Servers in a domain have the latest version of an application. At startup, a Managed Server queries its Administration Server to determine if it (the Managed Server) has the most recent version of the application. If an updated version of the application is available, it is copied to the Managed Server, and the Administration Server adds that Managed Server to the StagedTargets list.
When an Administration Server goes down, all Managed Servers are removed from the StagedTargets. When the Administration Server is rebooted, each Managed Server in the domain copies its deployed applications from the Administration Server. This assures that, in the event that an application has been updated while the Administration Server was down, all Managed Servers have the same version of the application.
Setting Default Encoding for JVM
Customers running WLS 6.1 SP04 and Sun JVM 1.3.1_06 attempted and failed to set the default encoding for the VM using the -Dfile.encoding attribute.
Since file.encoding is a read-only property this property cannot be changed, either on the command line or via the methods in the java.lang.System class.
Please see <http://developer.java.sun.com/developer/bugParade/bugs/4163515.html> and the related bugs for more details.
The preferred way to change the default encoding used by the VM and the runtime system is to change the locale of the underlying platform before starting your Java program.
With the release of WebLogic Server 6.1 SP04, BEA certified the Oracle 9.2.0 Thin Driver for use with WebLogic Server. The software distribution for WebLogic Server 6.1 SP04 includes the following new JDBC drivers:
For more information about using WebLogic jDriver for Oracle, see Installing and Using WebLogic jDriver for Oracle. For more information about using the Oracle Thin Driver with WebLogic Server, see Using Third-Party Drivers with WebLogic Server.
In the Oracle Thin Driver version 9.2.0, Oracle removed some extension methods that were previously available in the driver. These methods are no longer supported and are not included in WebLogic Server 6.1 SP04:
Class:
weblogic.jdbc.oracle.OracleConnection
Method:
isCompatibleTo816()
Class:
weblogic.jdbc.oracle.OracleStatement
Method:
getWaitOption()
setWaitOption(int i)
setAutoRollback(int i)
getAutoRollback()
Class:
weblogic.jdbc.oracle.OracleResultSet
Method:
getCURSOR(String s)
WebLogic Server 6.1 Service Pack 3
These sections describe bug fixes and key changes in WebLogic Server 6.1 SP03:
Changes in System Administration
This section lists key system administration changes in WebLogic Server 6.1 SP03.
Strict Enforcement of ACLs
In WebLogic Server 6.1 SP03, an error in the implementation of ACLs for JDBC was fixed, which makes ACLs very strict. If you define an ACL for connection pools, access is restricted to exactly what is defined in the ACL. For more information, see Permissions at ../jdbc/programming.html#programming006.
Changes in WebLogic jDriver Support
The following list details recent changes to supported versions of Oracle used with WebLogic jDriver for Oracle:
For more information, see Setting Up the Environment for Using WebLogic jDriver for Oracle in Installing and Using WebLogic jDriver for Oracle.
Oracle 9.0.1 Thin Driver Certification
For the release of WebLogic Server 6.1 SP03, BEA certified the Oracle 9.0.1 Thin Driver for use with WebLogic Server. For more information about using the Oracle Thin Driver with WebLogic Server, see Using Third-Party Drivers with WebLogic Server.
Changes in JMS
WebLogic Server 6.1 SP03 includes the WebLogic Messaging Bridge.
A messaging bridge is responsible for transferring messages between two messaging providers. The WebLogic Messaging Bridge allows you to configure a store-and-forward mechanism between any two messaging products—including separate implementations of WebLogic JMS.
For more information, see Using the WebLogic Messaging Bridge in the Administration Guide.
WebLogic Server 6.1 SP03 includes a new JMS message paging feature.
The WebLogic JMS Message Paging feature can free up valuable virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold. From a performance perspective, this feature can greatly benefit WebLogic Server implementations with the large message spaces that are required by today's enterprise applications.
Two metrics are used to determine when to start and stop paging: bytes paging and messages paging. Each metric is the basis of a single paging mode, which you can enable and disable individually, or use simultaneously, on JMS servers and/or destinations (topics and queues).
Paging is configured through the Administration Console. Using the paging attributes on the JMS Server node, you can specify a paging store for the server, enable bytes and/or messages paging, and configure the bytes/messages high and low thresholds to start and stop paging. Similarly, using the paging attributes on the Destinations node, you can configure bytes/messages paging for all topics and queues configured for the JMS server. The destinations use the paging store that is configured for the JMS server. Also, if you use JMS templates to configure multiple destinations, you can use the paging attributes on the Templates node to quickly configure message paging on all your destinations.
For detailed instructions on configuring message paging, see the section called "Tuning JMS" in the WebLogic Server Administration Guide.
WebLogic-Tuxedo Interoperability
WebLogic Server 6.1 SP3 interoperates with C++ clients using the Tuxedo 8.0 C++ Client ORB. Tuxedo release 8.0 RP 56 and above is required. WebLogic Server users should contact their BEA Service Representative for information on how to obtain the Tuxedo C++ Client ORB. For more information on how WebLogic Server interoperates with a Tuxedo C++ Client ORB, see RMI-IIOP with Tuxedo and Tuxedo Clients.
WebLogic Server 6.1 Service Pack 2
These sections describe bug fixes and key changes in WebLogic Server 6.1 SP02:
Compatibility Issues
This section describes compatibility issues in WebLogic Server 6.1 SP02.
Start Script Switch for WebLogic Server 6.1 SP02 Clients
By default, a WebLogic Server 6.1 SP02 client does not interoperate with a WebLogic Server 6.1 GA or 6.1 Service Pack 1 server. This is true both for a 6.1 SP2 client and a 6.1 SP2 server acting as a client to a 6.1 GA or 6.1 SP1 server.
To allow an SP2 client to talk to a 6.1 GA or 6.1 SP1 server, add the following switch to the WebLogic Server 6.1 SP02 start script:
-Dweblogic.61compat=true
SAX Parser and Encoding Error Detection
WebLogic Server's built-in SAX parser now correctly parses deployment descriptor files that are written using any character set.
Prior to this fix, WebLogic Server would have failed to detect encoding problems in your .xml files for English-only applications. Consequently, English-only applications that contained encoding problems and ran without fail in the past may now fail with this SP02 fix; WebLogic Server will report an encoding-not-supported error.
If WebLogic Server reports this error, check the specified .xml file for the correct encoding name and syntax.
Certifications
http://www.hp.com/products1/unix/java/infolibrary/patches.html
For current information regarding platform support, see the Supported Configurations at
Changes to Proxy Servlets
WebLogic Server 6.1 SP02 includes new versions of the HttpClusterServlet and the HttpProxyServlet that support the HTTP 1.1 protocol. In addition, these servlets now use the same configuration parameters as the Apache, Netscape, and Microsoft IIS plug-ins.
For more information see the following documents:
New Security Classes
WebLogic Server 6.1 SP02 includes two new classes related to security:
In addition, SP02 adds parameters for SSL session caching that eliminate the need for the connection to go through the SSL handshake again. For more information, see the section called "Modifying Parameters for SSL Caching" in "Managing Security".
Servlet and JSP Encoding Changes
As of WebLogic Server 6.1 SP02, the default encoding used for servlets and JSPs has been changed to ISO8859_1. Previously the default encoding used was the JVM default. This change is in accordance with the latest servlet specification. Servlet Specification 2.3 SRV 4.9 states that the default encoding should be ISO8859_1.
BEA recommends you explicitly set the encoding of the request and response objects in order to avoid any encoding problems. For further details on how to set encoding, see http://edocs.beasys.co.jp/e-docs/wls61/jconfig/wls61jconfig.html.
WebLogic 6.1 SP02 and 5.1 Interoperability
As of WebLogic Server 6.1 SP02, it is possible to bi-directionally interoperate with WebLogic 5.1 Servers. This allows a WebLogic 6.1 Server to remotely invoke EJBs or RMI objects hosted on a WebLogic 5.1 Server. It also allows the reverse-a WebLogic 5.1 Server can remotely invoke EJBs or RMI objects hosted on a WebLogic 6.1 Server. For further details, see the Interoperability Guide.
WebLogic Server 6.1 Service Pack 1
For information on problems solved in WebLogic Server 6.1 SP01, see WebLogic Server 6.1 Service Pack 1 Solutions.
WebLogic Server 6.1 (G.A. Release)
These sections describe WebLogic Server 6.1 features, provides certification and standards support information, and highlights key known issues in the General Availability (G.A.) release.
Notes for WebLogic APIs
Applets
A problem with the tools.jar shipped with the JDK prevents Applets from being served to the client correctly. If tools.jar is located in your server CLASSPATH, you must ensure that weblogic.jar appears in the server CLASSPATH before tools.jar.
Beanshell Code
WebLogic Server uses an open source product called Beanshell. The initial developer of the original Beanshell code is Pat Niemeyer. Portions created by Pat Niemeyer are Copyright (C) 2000. All Rights Reserved. Beanshell is available under the Sun Public License and the GNU Lesser General Public License. The source code to Beanshell can be found at http://www.beanshell.org.
Clustering
Clusters of WebLogic Servers do not require a shared network drive. Both the WebLogic Server installations and your applications can now reside on local file systems.
Clusters, DNS, and Multihoming on NT
Be aware of naming issues when using multihoming features on Windows NT in a cluster. For example, there may be naming conflicts if a cluster is running on a multihomed Windows NT machine and one of the servers in the cluster is bound to the same DNS name as the machine name. Attempts to contact that server using the DNS name in a URL may result in Windows NT converting that DNS name to any of the IP addresses of the multihomed Windows NT machine. In this case, the request may go to the wrong address. Avoid having DNS names that match your machine name.
Deployment in WebLogic Server 6.1
In WebLogic Server 6.1, updating an application on any single server instance to which it is targeted causes it to be updated on all servers to which is targeted. For instance, if an application is targeted to a cluster, and you update it on one of the clustered servers instances, the application will be updated on all members of cluster. Similarly, if the application is targeted to a cluster and to a standalone server instance, updating it on the standalone server instance will result in its update on the cluster, and vice versa.
If you want to be able to update an application or component selectively on a subset of the server instances to which it is targeted, deploy unique instances to of the application to different targets.
New Deployment Tutorial Available
WebLogic Server 6.1 includes a new deployment tutorial, called "Deploying an Exploded J2EE Application". It is available on the WebLogic Server Samples and Tutorials page.
WebLogic Server 6.1 includes many enhancements to WebLogic EJBs. For more information, see Programming WebLogic Enterprise JavaBeans.
WebLogic Server 6.1 is compliant with the JavaSoft EJB 1.1 Specification. WebLogic also contains an optional implementation of the preliminary EJB 2.0 specification. The WebLogic Server EJB documentation describes key features of the EJB 2.0 Specification that you need to understand in order to use WebLogic Server.
New EJB features in this release include:
EJB Pass By Value J2EE incompatibility
Many of the WebLogic Server EJB deployment properties have default values that are optimized for performance. In some cases, these default values are not compliant with the EJB specification. Should you wish to make WebLogic Server compliant with the EJB specification, you must set the following properties:
In weblogic-ejb-jar.xml set "enable call by reference" to False.
In weblogic-cmp-jar.xml, set "include-updates" to True
In weblogic-cmp-jar.xml, set "check exists on method" to True.
Hypertext Transfer Protocol (HTTP) 1.1
The following sections refer to HTTP features supported with WebLogic Server 6.1.
Web Server
WebLogic Server 6.1 is a functional Web server that can handle high-volume Web sites, serving static HTML (text) files as well as servlets and JavaServer Pages (JSP). WebLogic Server 6.1 can also fully integrate with hardware- and software-based Web load-balancing solutions. WebLogic Server 6.1 supports the HTTP 1.1 standard.
Each WebLogic Server 6.1 hosts a default Web server and any number of additional Web servers that you define. Each of these additional Web servers is configured to respond to a different DNS name, in a process called Virtual Hosting.
You configure the attributes for Web servers using the new WebLogic Server Administration Console.
For more information, see Programming WebLogic HTTP Servlets.
HTTP Plug-ins for Apache, Netscape, and IIS
WebLogic Server 6.1 automatically implements keep-alive connections between the plug-ins and WebLogic Server. WebLogic Server 6.1 also supports SSL when using the HTTP plug-ins.
The Apache plug-in is now available for Apache 2.0 (non-SSL only). The Apache 2.0 version also supports HTTP 1.1 keep-alive connections.
For more information on SSL and each of the plug-ins, see the WebLogic Server Administration Guide.
HTTP Session Persistence
A new option is available for persisting HTTP sessions using cookies. For more information, see "Configuring Session Persistence".
HTML Pages and Netscape
If you already have a Netscape browser running when you start WebLogic Server, some HTML pages will not display. For example, if you select the About WebLogic Server page from the Start menu, and you have Netscape running and do not have Microsoft Internet Explorer, the screen may flash but the page will not display.
J2EE Connector
BEA WebLogic Server continues to build upon the implementation of the Sun Microsystems J2EE Platform Specification, Version 1.3 by supporting the J2EE Connector architecture. The BEA WebLogic J2EE Connector architecture enables you to connect existing legacy applications to the J2EE platform. The goal is to leverage the strengths of the J2EE platform—including component models, transaction, and security infrastructures—to address the challenges of integrating existing legacy applications.
The connector architecture defines a common interface between application servers and legacy applications, implemented in application specific resource adapters that plug in to application servers. The result is simplified enterprise application integration, using a scalable, standard architecture that leverages the benefits of the J2EE platform.
For more information, see Programming the WebLogic J2EE Connector Architecture
Java Database Connectivity (JDBC)
The following items are new or improved JDBC features.
MultiPools
JDBC MultiPools create a list of connection pools to be used by a single instance of WebLogic Server. A configurable algorithm determines which connection is returned. MultiPools provide support for load balancing and high availability. MultiPools make it easier for an application to switch to another RDBMS for distributed processing or during a failover situation.
For more information, see Programming WebLogic JDBC.
JDBC-based Persistence
A new column, wl_max_inactive_interval, has been added to the wl_servlet_sessions table used for JDBC-based persistence. For information on the wl_servlet_sessions table, see the section "Using a Database for Persistent Storage".
WebLogic Server 6.1 includes an implementation of the JavaMail Specification. This is the standard reference implementation of the JavaMail Specification. For more information, see Developing WebLogic Server Applications
Java Transaction API (JTA)
WebLogic Server 6.1 supports distributed transactions and the two-phase commit protocol with a specification-compliant JTA implementation. This implementation works with any certified XA-compliant resource such as WebLogic JMS and the WebLogic jDriver for Oracle.
For more information, see Programming WebLogic JTA.
JMS
The following are new or improved features of JMS.
Asynchronous JMS
Now you can disable synchronous writes to JMS File Stores. This capability results in much improved performance at the expense of reliability. If JMS reliability is not critical to your application, you may benefit from this feature. For more information, see Programming WebLogic JMS.
Durable Subscription Management
A RuntimeMBean has been added for managing JMS durable subscriptions (JMSDurableSubscriberRuntimeMBean). Use this MBean to perform simple management tasks, such as monitoring, deleting, or modifying durable subscriptions, from the WebLogic Server Administration Console.
Redelivery Delay
You can delay the redelivery of messages when a temporary, external condition prevents an application from handling a message properly. When a message is rolled back or recovered, the RedeliveryDelay is the amount of time a message is delayed before redelivery is attempted.
If JMS immediately redelivers the message, the condition may not be clear and the application still may be unable to handle the message. Configuring an application for a RedeliveryDelay addresses this issue.
Time To Deliver
You can schedule message deliveries to an application for specific times in the future. Message deliveries can be deferred for short periods (such as seconds or minutes) or for long stretches (such as hours later for batch processing). You can also specify a relative TimeToDeliver (in milliseconds), which WebLogic JMS will then compute into an absolute DeliveryTime for a message. Until that DeliveryTime, the message is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.
Redelivery Limit
You can set a limit on the number of times that WebLogic JMS will attempt to redeliver a message to an application. Once WebLogic JMS fails to redeliver a message for a specific number of times, the message can be redirected to an ErrorDestination queue. If no ErrorDestination is configured, then the message is dropped.
The following JSP features are included with WebLogic Server 6.1:
Support for the following features of the JSP 1.2 specification from Sun Microsystems has been added. Version 1.2 of the specification is a proposed final draft of the specification and is subject to change. If you are planning to use JSP 1.2 features in your application, note that the specification has not been finalized and could change in the future.
WebLogic Server 6.1 security functionality includes:
For more information, see Programming WebLogic Security.
Default and Custom Login Modules
WebLogic Server uses the default LoginModule (weblogic.security.internal.ServerLoginModule) to gather authentication information during server initialization. To replace the default Login module, edit the server.policy file and replace the name of the default Login module with the name of a custom Login module.
Optionally, custom login modules can be specified in the server.policy file ahead of the default LoginModule. The JAAS implementation in WebLogic Server uses Login modules in the order in which they are defined in the server.policy file. The default Login module checks for existing system user authentication definitions prior to execution and does nothing if they are already defined.
The default Login module is required to define JVM properties for both the system username and password. These properties are specified as weblogic.management.username and weblogic.management.password respectively. In order to use a custom Login module, these properties must be set accordingly.
The following new features and changes apply to servlets and Web Applications:
Web Application Events provide notifications of a change in state of the servlet context (each Web Application uses its own servlet context) or of an HTTP session object. You can write event listener classes that respond to these changes in state. For more information, see Using Application Events and Listeners.
A filter is a Java class that is invoked in response to a request for a resource in a Web Application. These resources can include Java Servlets, JavaServer Pages (JSPs), or static resources such as HTML pages or images. A filter intercepts the request and can examine and modify the response and request objects or execute other tasks. For more information, see Using Filters.
Version 2.3 of the Servlet Specification from Sun Microsystems is a proposed final draft of the servlet specification and is subject to change. If you are planning to use any features introduced with version 2.3 in your application, note that the specification has not been finalized and could change in the future.
SNMP
WebLogic Server 6.1 can function as a Simple Network Management Protocol (SNMP) agent. The WebLogic SNMP agent runs as a service that responds to requests from SNMP managers and sends SNMP trap notifications to SNMP managers. The WebLogic SNMP agent uses standard Java Management Extension (JMX) interfaces to access WebLogic resources. For more information, see the WebLogic SNMP Management Guide.
Installation
WebLogic Server 6.1 includes an installation program that makes it easier to install WebLogic Server on both Windows and UNIX systems. The installer unpacks the distribution, performs basic configurations, and sets up shortcuts for using WebLogic Server. In addition, the JDK is included in the package so that the server is ready to run.
For details, see the WebLogic Server Installation Guide.
Internationalization
WebLogic Server 6.1 can deliver content in any language, including those languages that require double-byte character sets. For information about using the new internationalization API, see the WebLogic Server Internationalization Guide.
In addition, a Kanji version of WebLogic Server 6.1 will be available. For more information, contact your BEA sales representative.
Administration Console
Improvements to management architecture enable you to make dynamic configuration changes to running instances of WebLogic Server. A Web-based Administration Console is your window into the WebLogic Administration Service, an implementation of the Java Management Extension (JMX) standard. Using the Administration Console, you can configure attributes, deploy applications and components, monitor resource usage, view log messages, edit deployment descriptors and .xml files, and perform other management activities. Administration Console features include:
For more information, see the WebLogic Server Administration Guide.
Production Mode and Development Mode
There is now a flag that can be used to switch between production and development modes. When the server starts, it loads and deploys any applications that have configuration information in the config.xml file, whether you are using production or development mode. If you are running in development mode, the server will also deploy or redeploy any applications stored or placed in the ..\applications directories after startup. This is called dynamic deployment and is useful when you are developing your applications. If you shut down the server, the configuration information for any applications that were dynamically deployed is written to the config.xml file in the application's domain. The production/development flag can be added to the startup script for your domain. If it is not added, development mode will be activated. To change the mode:
1. With a text editor, open the start script for your domain.
2. Edit the line that begins set STARTMODE= to add the value true or false. True is for production mode, and false is for development mode.
Tools
WebLogic Server 6.1 includes the weblogic.refresh tool, which lets you refresh static components of an application without redeploying the application. Use weblogic.refresh to refresh, add, or delete static files such as:
WebLogic Tuxedo Connector
In WebLogic Server Release 6.1, the WebLogic Tuxedo Connector has the following limitations:
WebLogic-Tuxedo Interoperability
WebLogic Tuxedo Connector (WTC) provides interoperability between WebLogic Server applications and Tuxedo ATMI, CORBA Java, and CORBA C++ server applications. WTC tBridge functionality provides Tuxedo /Q and JMS advanced messaging services. For more information, see the WebLogic Tuxedo Connector Guide.
BEA WebLogic C++ Client
WebLogic Server 6.1 SP3 interoperates with C++ clients using the Tuxedo 8.0 C++ Client ORB. Tuxedo release 8.0 RP 56 and above is required. WebLogic Server users should contact their BEA Service Representative for information on how to obtain the Tuxedo C++ Client ORB. For more information on how WebLogic Server interoperates with a Tuxedo C++ Client ORB, see RMI-IIOP with Tuxedo and Tuxedo Clients.
WebLogic Server 6.1 supports XML as an essential component. JSPs can be used to generate and consume XML between servers or between a server and clients. WebLogic Server 6.1 supports XSL processing tags for JSPs. EJBs use XML to describe deployment properties, which provides data portability. The server provides an XML schema repository for DTDs, managed by the Administration Console.
The XML subsystem of WebLogic Server 6.1 includes the following new features and improvements:
For more information on XML, see Programming WebLogic XML.
XML Editor
WebLogic Server now provides a simple, user-friendly tool for creating and editing XML files. It can validate XML code according to a specified DTD or XML Schema. The XML editor can be used on Windows or Solaris machines and can be downloaded from dev2dev Online.
Deprecated Features and APIs
The following features are deprecated in WebLogic Server 6.1 and will not be supported in the future:
For a list of deprecated WebLogic Server classes, see http://download.oracle.com/docs/cd/E13222_01/wls/docs61/javadocs/deprecated-list.html.
Documentation and Examples
The examples included with WebLogic Server 6.1 now include ant build scripts. These scripts accompany the examples as build.xml files and can be run on any platform supported by WebLogic Server 6.1. Execute these build scripts on a command line by locating the proper directory for that example and typing:
ant
The following documentation and examples are new to WebLogic Server 6.1:
The WebLogic Server Tour is revised. It provides an overview of WebLogic Server using the Pet Store application to demonstrate features. The Tour is available from the Start menu. The Pet Store is now based on version 1.1.2 of Sun's Java Pet Store and has been upgraded to use build scripts with Ant 1.3.
J2EE and Standards Topics
A JDK provides a Java runtime environment (the Java Virtual Machine or JVM) and tools for compiling and debugging your Java applications. Your installation of WebLogic Server 6.1 includes the 1.3.1rc2 JDK from Sun Microsystems.
BEA WebLogic Server 6.1 is the first e-commerce transaction platform to implement advanced J2EE 1.3 features. To comply with the rules governing J2EE, BEA Systems provides two separate downloads: one with J2EE 1.3 features enabled, and one that is limited to J2EE 1.2 features only. Both downloads offer the same container and differ only in the APIs that are available.
WebLogic Server 6.1 with J2EE 1.2 Plus Additional J2EE 1.3 Features
With this download, WebLogic Server defaults to running with J2EE 1.3 features enabled. These features include EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0. When you run WebLogic Server 6.1 with J2EE 1.3 features enabled, J2EE 1.2 applications are still fully supported. The J2EE 1.3 feature implementations use non-final versions of the appropriate API specifications. Therefore, application code developed for BEA WebLogic Server 6.1 that uses the new features of J2EE 1.3 may be incompatible with the J2EE 1.3 platform supported in future releases of BEA WebLogic Server.
The sections below list the J2EE 1.3 API classes and deployment descriptors that are not implemented in WebLogic Server 6.1.
Enterprise Java Beans Deployment Descriptors
WebLogic Server 6.1 fully implements all EJB 2.0 deployment descriptors defined in Sun Microsystem's ejb-jar.xml document type definitions (DTD) file with the following exceptions:
Note: The ejb-jar.xml document type definitions (DTD) file is part of Sun Microsystem EJB 2.0 specification.
JDBC API Classes
JSP 1.2 API Classes
|
API |
Class |
Differs from J2EE 1.3 |
|---|---|---|
|
javax.servlet.jsp |
java.beans.Beans |
The jsp:id mechanism has not been implemented |
Note: The following feature has not been implemented:
A JAR containing a packaged tag libraries can be dropped into the WEB-INF/lib directory to make its classes available at request time.
JSP 1.2 Deployment Descriptors
Servlet API Classes
Servlet Deployment Descriptors
WebLogic Server 6.1 fully implements all Servlet 2.3 deployment descriptors with the following exceptions:
WebLogic Server 6.1 with J2EE 1.2 Certification
With this download, WebLogic Server defaults to running with J2EE 1.3 features disabled and is fully compliant with the J2EE 1.2 specification and regulations.
Product CD Installers for J2EE 1.2 and 1.3
In addition to being available at http://commerce.bea.com/downloads/products.jsp, both distributions are provided on the WebLogic Server 6.1 product CD. (On Windows machines, the installer for WebLogic Server with J2EE 1.3 features enabled starts automatically when you insert the CD.)
Standards Support
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|