InfoCenter Home >
4: Developing applications >
4.3: Developing enterprise beans >
4.3.1: Late-breaking enterprise beans programming tips

4.3.1: Late-breaking enterprise beans programming tips

This article provides programming tips and considerations to supplement the Writing Enterprise Beans book. Also see the product Release Notes.

EJB jar files that contain both source and class files result in compile errors or exceptions

Ensure your jar files only contain class files, images, and sounds. Source (.java) files in your jar file will cause exceptions when you run the application, or compile errors when you compile the source.

Disregard README.rmi-iiop / README.RMI-IIOP

The product installs an unnecessary file:

product_installation_root/java/README.RMI-IIOP

If you encounter this file, disregard it. It instructs you to rename an rmictools.jar file that does not exist. Because the wstools.jar is already installed, containing the necessary IBM implementations for IIOP, you do not need to rename the file in order to use the IBM rmic (Remote Method Invocation) compiler.

Avoid creating or accessing protected enterprise beans in the servlet init() method

The Writing Enterprise Beans book contains a discussion of servlet init() methods in the context of developing servlets that use enterprise beans. Here is some additional information about the security aspect.

Although the init method is a good place to get references to EJB home objects, it is not a good place to create enterprise beans or access other enterprise beans that might be protected with WebSphere security. Depending on the authorization policy on the protected objects, creating or accessing these objects from within the servlet init() method could fail for authentication or authorization reasons because they were not accessed with the proper security credentials.

Creating or accessing protected objects should be done after the init() method, in one of the doXXX methods of the servlet.

Deployment tool limitations

The enterprise bean deployment tool provided by WebSphere Application Server maps all non-primitive Java types to serialized BLOB objects when the beans are using a DB2 database. For example, when a CMP bean with field java.math.BigDecimal is deployed on DB2, its field becomes a BLOB data type.

If you need to map non-primitive types to other, more complex data types, consider using IBM VisualAge for Java for deployment.

Inheritance by remote objects

An enterprise bean or other remote object cannot inherit from two interfaces that have methods with the same name, even if those methods have different signatures, due to the Java-IDL mapping specification.

Java programmers accustomed to the usual Java inheritance model should take care to note this limitation of the specification. By the Enterprise JavaBeans (EJB) specification, enterprise beans should not be written to inherit from two interfaces as described above. If they do, they will encounter errors when deployed.

Option A caching incompatible with clusters and shared data

When Option A caching is in use, the application server hosting the enterprise bean container must be the only updater of the data in the persistent store. As such, Option A caching is incompatible with:

  • Workload managed servers (such as a cluster of clones)
  • Database with data being shared among multiple applications

Shared database access corresponds to Option C caching. See the EJB specification for futher details.

Option A and Option C caching are also known as commit option A and commit option C, respectively.

Best practice for data source ID and password

Although it is not necessary, it is good practice to specify the user ID and password for a data source either in the enterprise bean to be using the data source, or the container of the bean.

Developer's Client Files for setting up Java application clients

In "Developing EJB clients," the Writing Enterprise Beans book states:

The Java client object request broker (ORB), which is automatically initialized in EJB clients, does not support dynamic download of implementation bytecode from the server to the client. As a result, all classes required by the EJB client at runtime must be available from the files and directories identified in the client's CLASSPATH environment variable. For information on the JAR files required by EJB clients, see Setting the CLASSPATH environment variable in the EJB server (AE) environment or Setting the CLASSPATH environment variable in the EJB server (CB) environment.

Article 1.4 about installable components describes how to install the needed files on your machine. See the table entry for "full Java application client."

Note a possible book correction: The English version of the Writing Enterprise Beans book refers only to one of two installation options presented in article 1.4.1 -- you might need the option that it does not mention. The translated versions of the book do not mention either option for installing a full Java application client.

Commiting transactions based on EJB 1.1 specification

According to the EJB specifications, if an enterprise bean container catches an exception from the business method of an enterprise bean, and the method is running within a container managed transaction, the container should rollback the transaction before passing the exception on to the client.

However, if the business method is throwing an Application exception as defined in Chapter 12 of EJB 1.1 specification, then the normal behavior for the container in this case is to COMMIT the transaction. Even though IBM WebSphere Application Server Version 3.5 does not officially support the EJB 1.1. specification level, in such a case it behaves as determined by the 1.1. specification. If a business method throws an exception, the container will commit the transaction before re-throwing the exception.

EJB clients need ioser library to run

If using Windows NT, ensure that EJB clients can locate the following library file at their run time: ioser.dll

References to jar file, iioptools.jar, should be ignored.

The Writing Enterprise Beans book contains many references to file, iioptools.jar. These references should be ignored. This was a required jar file for JDK levels prior to JDK 1.2.2, and had to be defined in the CLASSPATH for WebSphere Application Server to execute successfully. With JDK 1.2.2, file, iioptools.jar, was incorporated into the runtime environment, and no longer needs to be included in the CLASSPATH. In fact, with JDK 1.2.2, file, iioptools.jar, no longer exists.

Go to previous article: Developing enterprise beans Go to next article: JNDI caching

 

 
Go to previous article: Developing enterprise beans Go to next article: JNDI caching