EJB.18.2 Container Provider s Responsibility | Java 2 Platform, Enterprise Edition: Platform and Component Specifications

EJB.18.2 Container Provider's Responsibility

This section defines the container's responsibilities for providing the runtime environment to the enterprise bean instances. The requirements described here are considered to be the minimal requirements; a container may choose to provide additional functionality that is not required by the EJB specification.

EJB.18.2.1 Java 2 Platform-Based Container

A Java 2 platform-based EJB container must make the following APIs available to the enterprise bean instances at runtime:

Java 2 APIs
EJB 1.1 APIs
JNDI 1.2
JTA 1.0.1, the UserTransaction interface only
JDBC 2.0 extension
JavaMail 1.1, sending mail only

The following subsections describe the requirements in more detail.

EJB.18.2.1.1 Java 2 APIs Requirements

The container must provide the full set of Java 2 platform APIs. The container is not allowed to subset the Java 2 platform APIs.

The EJB container is allowed to make certain Java 2 platform functionality unavailable to the enterprise bean instances by using the Java 2 platform security policy mechanism. The primary reason for the container to make certain functions unavailable to enterprise bean instances is to protect the security and integrity of the EJB container environment, and to prevent the enterprise bean instances from interfering with the container's functions.

Table EJB.18-1 defines the Java 2 platform security permissions that the EJB container must be able to grant to the enterprise bean instances at runtime. The term "grant" means that the container must be able to grant the permission; the term "deny" means that the container should deny the permission.

Table EJB.18-1. Java 2 Platform Security Policy for a Standard EJB Container

Permission Name	EJB Container Policy
`java.security.AllPermission`	deny
`java.awt.AWTPermission`	deny
`java.io.FilePermission`	deny
`java.net.NetPermission`	deny
`java.util.PropertyPermission`	grant `"read"` , `"*"` deny all other
`java.lang.reflect.ReflectPermission`	deny
`java.lang.RuntimePermission`	grant `"queuePrintJob"` , deny all other
`java.lang.SecurityPermission`	deny
`java.io.SerializablePermission`	deny
`java.net.SocketPermission`	grant `"connect"` , `"*"` ^[a] , deny all other

^[a] This permission is necessary, for example, to allow enterprise beans to use the client functionality of the Java IDL API and RMI-IIOP packages that are part of Java 2 platform.

Some containers may allow the deployer to grant more, or fewer, permissions to the enterprise bean instances than specified in Table EJB.18-1. Support for this is not required by the EJB specification. Enterprise beans that rely on more or fewer permissions will not be portable across all EJB containers.

EJB.18.2.1.2 EJB 1.1 Requirements

The container must implement the EJB 1.1 interfaces as defined in this documentation.

EJB.18.2.1.3 JNDI 1.2 Requirements

At the minimum, the EJB container must provide a JNDI API name space to the enterprise bean instances. The EJB container must make the name space available to an instance when the instance invokes the javax.naming.InitialContext default (no-arg) constructor.

The EJB container must make available at least the following objects in the name space:

The home interfaces of other enterprise beans
The resource factories used by the enterprise beans

The EJB specification does not require that all the enterprise beans deployed in a container be presented with the same JNDI API name space. However, all the instances of the same enterprise bean must be presented with the same JNDI API name space.

EJB.18.2.1.4 JTA 1.0.1 Requirements

The EJB container must include the JTA 1.0.1 extension, and it must provide the javax.transaction.UserTransaction interface to enterprise beans with bean-managed transaction demarcation through the javax.ejb.EJBContext interface, and also in JNDI under the name java:comp/UserTransaction , in the cases required by the EJB specification.

The EJB container is not required to implement the other interfaces defined in the JTA specification. The other JTA interfaces are low-level transaction manager and resource manager integration interfaces, and are not intended for direct use by enterprise beans.

EJB.18.2.1.5 JDBC 2.0 Extension Requirements

The EJB container must include the JDBC 2.0 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level XA and connection pooling interfaces. These low-level interfaces are intended for integration of a JDBC driver with an application server, not for direct use by enterprise beans.

EJB.18.2.2 JDK 1.1 Based Container

A JDK 1.1 based EJB container must make the following APIs available to the enterprise bean instances at runtime:

JDK 1.1 or higher
EJB 1.1 APIs
JNDI 1.2
JTA 1.0.1, the UserTransaction interface only
JDBC 2.0 extension
JavaMail 1.1, sending mail only

The following subsections describes the requirements in more detail.

EJB.18.2.2.1 JDK 1.1 APIs Requirements

The container must provide the full set of JDK 1.1 APIs. The container is not allowed to subset the JDK 1.1 APIs.

The EJB container is allowed to make certain JDK 1.1 functionality unavailable to the enterprise bean instances by using the JDK security manager mechanism. The primary reason for the container to make certain functions unavailable to enterprise bean instances is to protect the security and integrity of the EJB container environment, and to prevent the enterprise bean instances from interfering with the container's functions.

Table EJB.18-2 defines the JDK 1.1 security manager checks that the EJB container must allow to succeed when the check is invoked from an enterprise bean instance.

Table EJB.18-2. JDK 1.1 Security Manager Checks for a Standard EJB Container

Security Manager Check	EJB Container's Security Manager Policy
`checkAccept(String, int)`	throw `SecurityException`
`checkAccess(Thread)`	throw `SecurityException`
`checkAccess(ThreadGroup)`	throw `SecurityException`
`checkAwtEventQueueAccess()`	throw `SecurityException`
`checkConnect(String, int)`	allow
`checkConnect(String, int, Object)`	allow
`checkCreateClassLoader()`	throw `SecurityException`
`checkDelete(String)`	throw `SecurityException`
`checkExec(String)`	throw `SecurityException`
`checkExit(int)`	throw `SecurityException`
`checkLink(int)`	throw `SecurityException`
`checkListen(int)`	throw `SecurityException`
`checkMemberAccess(Class, int)`	throw `SecurityException`
`checkMulticast(InetAddress)`	throw `SecurityException`
`checkMulticast(InetAddress, byte)`	throw `SecurityException`
`checkPackageAccess(String)`	throw `SecurityException`
`checkPackageDefinition(String)`	throw `SecurityException`
`checkPrintJobAccess()`	allow
`checkPropertiesAccess()`	throw `SecurityException`
`checkPropertyAccess(String)`	allow read of all properties
`checkRead(FileDescriptor)`	throw `SecurityException`
`checkRead(String)`	throw `SecurityException`
`checkRead(String, Object)`	throw `SecurityException`
`checkSecurityAccess(String)`	throw `SecurityException`
`checkSetFactory()`	throw `SecurityException`
`checkSystemClipboardAccess()`	throw `SecurityException`
`checkTopLevelWindow(Object)`	throw `SecurityException`
`checkWrite(FileDescriptor)`	throw `SecurityException`
`checkWrite(String)`	throw `SecurityException`

EJB.18.2.2.2 EJB 1.1 Requirements

The container must implement the EJB 1.1 interfaces as defined in this documentation.

EJB.18.2.2.3 JNDI 1.2 Requirements

Same as defined in Section EJB.18.2.1.3.

EJB.18.2.2.4 JTA 1.0.1 Requirements

Same as defined in Section EJB.18.2.1.4.

EJB.18.2.2.5 JDBC 2.0 Extension Requirements

Same as defined in Section EJB.18.2.1.5, with the following exception: The EJB container is not required to provide the support for the RowSet functionality.

This exception was made because the RowSet functionality requires the Java 2 Collections.

EJB.18.2.3 Argument Passing Semantics

The enterprise bean's home and remote interfaces are remote interfaces for Java RMI. The container must ensure the semantics for passing arguments conform to Java RMI. Non-remote objects must be passed by value.

Specifically, the EJB container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same Java virtual machine. Doing so could result in the multiple beans sharing the state of an object in the Java progarmming language, which would break the enterprise bean's semantics.