J2EE Doc Bundle Home

Java

JavaTM 2 SDK, Enterprise Edition 1.3.1 Release Notes

 


Revised: 1/10/02

Contents

Beginning with the J2EETM SDK

First time users of the JavaTM 2 SDK, Enterprise Edition (J2EETM SDK) should follow these steps:

1. Read the Installation Instructions to find out how to set the J2EE_HOME and JAVA_HOME environment variables. The Installation Instructions are on our web site and may be reached by a link on the J2EE SDK download page.

2. Install the software that the JavaTM 2 SDK, Enterprise Edition relies on. See the Required Software section of this document.

3. Go to the J2EE Tutorial to learn how to use the J2EE SDK. The J2EE Tutorial is found at:

http://java.sun.com/j2ee/tutorial/index.html

What's New in J2EE SDK 1.3.1

The 1.3.1 release of the J2EE SDK is an incremental release adding the following new features to the FCS 1.3 release:

Patch Release 1.3_01

Patch release 1.3_01 updated the 1.3 FCS release to correct problems that affected the portability of applications developed with the J2EE SDK:

New Features in J2EE SDK 1.3

The 1.3 FCS release of the J2EE SDK was a major release that implemented the following new features:

Supported Platforms

The 1.3.1 release of the J2EE SDK continues to support the following platforms:

Supported Databases and JDBCTM Drivers

The 1.3.1 release supports database drivers that conform to versions 1.0 and 2.0 of the JDBC API. We have performed tests with the following database servers:

For more information on JDBC technology, see the JDBC Data Access API web page. For a list of links to driver vendors, see the JDBC Technology Drivers page.

After you've installed your driver, follow the instructions in the JDBC Drivers section of the Configuration Guide to configure the driver for use with the J2EE SDK. If you are using the Cloudscape DBMS included in this release, you do not have to configure its driver.

See the section New Treatment of Non-XA Data Transactions, for additional driver related information.

What This Release Includes

The 1.3.1 release of the JavaTM 2 SDK, Enterprise Edition includes the following software.

J2EE Server

The J2EE server supports the following J2EE APIs and technologies:

Tools

Additional information about these tools can by found by consulting the J2EE SDK Tools document included with this bundle.

Cloudscape DBMS

This release includes Cloudscape (v. 4.0.6), a relational DBMS written in the JavaTM programming language. Although the documented code examples were tested with a Cloudscape database, you may use any database that meets the requirements described in the section, Supported Databases and JDBCTM Drivers.

Required Software

The Java 2 SDK, Enterprise Edition (J2EE) requires you to install the Java 2 SDK, Standard Edition (J2SETM). You need the J2SE SDK to run the J2EE server and to build and run J2EE applications. If your J2EE application client resides on a different machine than the J2EE server, then you must install the J2SE SDK on both the server and client machines. (This rule applies only to J2EE application clients, not to Web browser clients.)

This release of the J2EE SDK requires the versions of the J2SE SDK listed in the following table:

TABLE 1 Required Versions of the J2SE SDK

Operating System

J2SE SDK Version

SolarisTM 7 Operating Environment
SolarisTM 8 Operating Environment
1.3.1_02
Windows NT 4.0,
Windows 2000 Professional
1.3.1_02
Linux Redhat, v. 6.2 1.3.1_02

Note: Versions of the J2SE SDK not listed in the preceding table have not been tested and are not supported. For example, the J2SE SDK v. 1.2 will not work with this release of the J2EE SDK.

Current Limitations

The purpose of the J2EETM SDK is to introduce you to Java 2 Enterprise Edition technology and to provide you with an opportunity to give us feedback on the work we've done so far. This release has several limitations.

Multi-byte Character String Support

The current release does not support the use of multi-byte strings in EJB class names and JNDI names.

Database Calls During Result Set Iteration

With some JDBC drivers you cannot access the database while iterating through a result set. In the following code example, the stmt.executeUpdate call will fail:

String query = "SELECT DEPTNO FROM DEPT . . .";
String update = "UPDATE EMPLOYEE . . .";
ResultSet rs = stmt.executeQuery(query);
while (rs.next()) {
   String s = rs.getString("DEPTNO");
   // The following statement will FAIL:
   stmt.executeUpdate(update);
   . . .
}
You may be able to get around this limitation by trying the following approaches:

1. Use a stored procedure that contains the same SQL calls.

2. Substitute an iteration with a single SQL statement that contains a subquery. Here's an example:

String update = "UPDATE EMPLOYEE
    SET DEPTNO =
      (SELECT DEPTNO FROM DEPT
       WHERE LOC = `ATLANTA')
   WHERE TITLE = `ENGINEER'";
3. Call another method that issues the second SQL statement. The method must use the RequiresNew transaction attribute. If you try this approach, you should be aware that the second SQL statement is executed in another transaction. Therefore, if the second transaction fails, you need to mark the first transaction for rollback.

Scalability and Memory Requirements

The minimum memory requirement is 128 MB of memory. We recommend 256 MB for larger applications.

In the J2SE 1.3.1 softeare, an OutOfMemoryError can result when a very large number of classes are loaded by the Java virtual machine, even when there are free spaces on the Java heap. Workaround: Edit bin/setenv.sh or bin/setenv.bat to add the following option to the JAVACMD variable:

-XX:MaxPermSize=256M
See also

http://developer.java.sun.com/developer/bugParade/bugs/4390238

Common Development Environment

Each developer should work with his or her own J2EE SDK installation. Multiple developers should not share the same J2EE server.

RMI-IIOP and JAXP Standard Extensions

The J2EE SDK will not work with a J2SE installation which has the RMI-IIOP and JAXP standard extensions. The j2ee.jar file of the J2EE SDK already has the RMI-IIOP and JAXP classes. Workaround: Use a fresh J2SE installation without the standard extensions.

Known Bugs

TABLE 2 Known Bugs for This Release

Bug ID

Description

4461245 The SQL generator in the deploytool generates database table names for storing the persistent state of CMP entity beans. The table name is based on the bean class name. If there are two or more beans with the same bean class name (in the same EAR or in multiple deployed EARs), the table names will conflict. Workarounds: Use different datasources for storing beans in different EARs. Or, change the table names in the generated SQL statements in the Deployment Settings dialog for entity beans.
4533469 RMIC generates an incorrect stub when compiling an EJB remote interface of the following form:

public interface Foo extends EJBObject {

  public boolean isFoo() throws RemoteException;

  ...

}

This bug only occurs when the method name is of the form is<Name> where <Name> is the name of the EJB remote interface. In addition, the method takes no arguments and returns a boolean. When this method is called, the system may throw a CORBA BAD_OPERATION exception. Workaround: Rename the interface name or the method name.

Differences Between Tomcat and the J2EE SDK

Tomcat is an implementation of the JavaServer Pages and Servlet specifications. This version of the J2EE SDK includes Tomcat version 4.0.2.

Note: The Tomcat implementation in the J2EE SDK might be slightly different from the version of Tomcat 4.0.2 distributed separately because of different release schedules. For more information about Tomcat, please see http://jakarta.apache.org/.

Linux Notes

Port Conflicts

The network services of Redhat 6.2 (with Gnome) and the Eudora e-mail client use port 1050. By default, the J2EE server also uses this port. If this port conflict occurs, you will see the following error message when you start the J2EE server in verbose mode:

j2ee -verbose
. . .
J2EE server Listen Port: = 1050
java.lang.RuntimeException: 
Could not initialize j2ee server. 
Possible cause could be another instance of the server already 
running.
. . .
To fix this problem, change the default port numbers in the $J2EE_HOME/config/orb.properties file. For example, you can add a zero to each port number in the orb.properties file:

port=10590
host=localhost

Interoperability Between EJBTM Containers

Starting with version 1.3, the J2EE SDK implements all requirements for EJB container interoperability as defined by the Enterprise JavaBeans 2.0 specifications. With this interoperability feature, enterprise beans in the J2EE SDK can communicate with clients that run on application servers provided by other vendors, as long the application servers implement the specified interoperability requirements. The clients can include servlets, JSP pages, J2EE application clients, and enterprise beans.

To communicate with an enterprise bean running on the J2EE SDK server, the client running on an application server provided by another vendor must have the j2ee-ri-svc.jar file in its class path.

A client is running on the J2EE SDK server doe not need the j2ee-ri-svc.jar file to communicate with an enterprise bean on an application server provided by another vendor.

The j2ee-ri-svc.jar file is located in the lib directory of the J2EE SDK installation. It contains portable system value classes such as implementations of javax.ejb.Handle and javax. ejb.EJBMetaData. These implementations are specific to the J2EE SDK.

For more information on EJB container interoperability, please refer to section 19.2 of the Enterprise JavaBeans 2.0 specifications. A link to the specifications may be found on the J2EE SDK download page.

Container-Managed Persistence 2.0

The architecture for container managed persistence (CMP) was enhanced in the J2EE SDK 1.3 release. Please see the EJB 2.0 specifications for details.

Note that the persistence manager in the J2EE SDK only supports forward mapping of a CMP 2.0 abstract schema to a relational database. Using the J2EE SDK's tools, it is not possible to reverse map from existing database tables to a CMP 2.0 abstract schema.

deploytool Enhancements

In the 1.3.1 J2EE SDK release, the deploytool has an enhanced update function. The update function now locates files for inclusion in the deployed application by using search paths that are provided by the user. If some files are not found, the user is shown a split screen with the found files listed in the upper half of the Entries Changed dialog. Clicking on a file in the list displays the path used for locating the file. The user can verify that the intended file has been found, or edit the search path to bring in the correct file.

Files that have not been found are listed in the lower half of the dialog, under Entries Not Found on Diskn. Files can be moved into the found category by editing the search path so that they will be located by the program.

The screen for editing search paths is accessed by clicking the Edit Path button on the dialog.

Other Improvements

The deploytool has been improved in other, less visible ways. Intelligent field completion has been enhanced with improved filtering of local/remote interfaces and with the automatic entry of primary key classes for Container Managed Persistence (CMP) 2.0.

New Treatment of Non-XA Data Transactions

In the 1.3.1 release of the J2EE SDK, transactions using non-XA data-sources are treated as local transactions in order to improve performance.

Note ¯ Database drivers that support XA data-sources allow you to connect to multiple databases and to distribute transactions across machines or processes. JDBC 1.0 drivers do not support XA data sources. Some JDBC 2.0 drivers support XA data-sources and some do not. See the Configuration Guide for information about the installation of XA and non-XA drivers.

A local transaction is restricted to the use of exactly one non-XA data-source and to transactions that are completed within one Java virtual machine. Thus, a global transaction is not started and there is no need to go to the JTS layer. The resulting optimization results in a vast improvement in performance of begin/commit operations. With a local transaction there is no need for two-phase commits. The use of multiple non-XA data-sources or multiple Java virtual machines would require two-phase commits.

Breaking out local transactions will allow many uses of non-XA data-sources to be optimized. When two non-XA data sources are needed, they can be used by declaring them to be XA data sources in the J2EE SDK's resource.properties file.

If more than one resource is used in a transaction, non-XA data sources must not be used. (Examples of resources are relational databases accessed through the JDBC API, JMS queues and topics, and EISs accessed through the J2EE Connector architecture.) Instead, all resources must support XA transactions. It is illegal to use more than one non-XA data source in the same transaction.

Previously, the J2EE SDK committed multiple non-XA data-sources without doing a two-phase commit. This non-compliant procedure could result in a loss or corruption of data.



Copyright © 2002 Sun Microsystems, Inc. All rights reserved.