Sun Microsystems Inc.

word information for each resource manager connection factory reference declared by the enterprise bean, and the Container must be able to use the user/password combination for user authentication when obtaining a connection to the resource by invoking the resource manager connection factory.

Although not required by the EJB specification, we expect that Containers will support some form of a single sign-on mechanism that spans the application server and the resource managers. The Container will allow the Deployer to set up the resource managers such that the EJB caller principal can be propagated (directly or through principal mapping) to a resource manager, if required by the application.

While not required by the EJB specification, most EJB Container providers also provide the following features:

•A tool to allow the System Administrator to add, remove, and configure a resource manager for the EJB Server.

•A mechanism to pool connections to the resources for the enterprise beans and otherwise manage the use of resources by the Container. The pooling must be transparent to the enterprise beans.

14.4.4 System Administrator’s responsibility

The System Administrator is typically responsible for the following:

• Add, remove, and configure resource managers in the EJB Server environment.

In some scenarios, these tasks can be performed by the Deployer.

14.5 Deprecated EJBContext.getEnvironment() method

The environment naming context introduced in EJB 1.1 replaces the EJB 1.0 concept of environment properties.

An EJB 1.1 compliant Container is not required to implement support for the EJB 1.0 style environment properties. If the Container does not implement the functionality, it should throw a RuntimeException (or subclass thereof) from the EJBContext.getEnvironment() method.

If an EJB 1.1 compliant Container chooses to provide support for the EJB 1.0 style environment properties (so that it can support enterprise beans written to the EJB 1.0 specification), it should implement the support as described below.

When the tools convert the EJB 1.0 deployment descriptor to the EJB 1.1 XML format, they should place the definitions of the environment properties into the ejb10-properties subcontext of the environment naming context. The env-entry elements should be defined as follows: the env-entry-name element contains the name of the environment property, the env-entry-type must be java.lang.String, and the optional env-entry-value contains the environment property value.

Sun Microsystem Inc

For example, an EJB 1.0 enterprise bean with two environment properties foo and bar, should declare the following env-entry elements in its EJB 1.1 format deployment descriptor.

...

<env-entry> env-entry-name>ejb10-properties/foo</env-entry-name> <env-entry-type>java.lang.String</env-entry-type>

</env-entry> <env-entry>

<description>bar’s description</description> <env-entry-name>ejb10-properties/bar</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>bar value</env-entry-value>

</env-entry>

...

The Container should provide the entries declared in the ejb10-properties subcontext to the instances as a java.util.Properties object that the instances obtain by invoking the EJBContext.getEnvironment() method.

The enterprise bean uses the EJB 1.0 API to access the properties, as shown by the following example.

public class SomeBean implements SessionBean { SessionContext ctx;

java.util.Properties env;

public void setSessionContext(SessionContext sc) { ctx = sc;

env = ctx.getEnvironment();

}

public someBusinessMethod(...) ... {

String fooValue = env.getProperty("foo"); String barValue = env.getProperty("bar");

}

...

}

14.6 UserTransaction interface

Note: The requirement for the Container to publish the UserTransaction interface in the enterprise bean’s JNDI API context was added to make the requirements on UserTransaction uniform with the other Java 2 platform, Enterprise Edition application component types.

The Container must make the UserTransaction interface available to the enterprise beans that are allowed to use this interface (only session beans with bean-managed transaction demarcation are allowed to use this interface) in JNDI API under the name java:comp/UserTransaction.

Sun Microsystems Inc.

The Container must not make the UserTransaction interface available to the enterprise beans that are not allowed to use this interface. The Container should throw javax.naming.NameNotFoundException if an instance of an enterprise bean that is not allowed to use the UserTransaction interface attempts to look up the interface in JNDI API.

The following code example

public MySessionBean implements SessionBean {

...

public someMethod()

{

Context initCtx = new InitialContext(); UserTransaction utx = (UserTransaction)initCtx.lookup(

“java:comp/UserTransaction”);

utx.begin();

...

utx.commit();

}

...

}

is functionally equivalent to

public MySessionBean implements SessionBean { SessionContext ctx;

...

public someMethod()

{

UserTransaction utx = ctx.getUserTransaction(); utx.begin();

...

utx.commit();

}

...

}