<res-auth> tells the server who is responsible for authentication. It can have two values:
CONTAINER is specified, the servlet container (the J2EE server) handles authentication before binding the factory to JNDI, using credentials provided by the deployer. If
SERVLET is specified, the servlet must handle authentication duties programmatically. To demonstrate:
InitialContext initCtx = new InitialContext( );
DataSource source =
// If "CONTAINER"
Connection con1 = source.getConnection( );
// If "SERVLET"
Connection con2 = source.getConnection("user", "password");
These tags too have similar counterparts in the EJB deployment descriptor. The only difference is that in EJB the two possible values for
Application (note the inexplicable case difference).
Servlet Distribution in a J2EE Environment
The final difference between servlets in a standalone environment and servlets in a J2EE environment involves a subtle change to the rules for session distribution. While a standard web server is required to support only
java.io.Serializable objects in the session for a distributable application, a J2EE-compliant server that supports a distributed servlet container must also support several additional types of objects:
All these are interfaces that do not implement
Serializable. For transferring the objects the container may use its own custom mechanism, perhaps based on serialization or perhaps not. Additional class types may be supported at the server's discretion, but these are the only guaranteed types.
Return to ONJava.com.