This chapter lists the requirements for web containers that are included in products that also include other Java technologies.
In the following sections any reference to Java EE applies to not only the full Java EE profile but also any profile that includes support for Servlet, like the Java EE Web Profile. For more information on profiles please refer to the Java EE platform specification.
Distributed servlet containers that are part of a Java EE implementation must support the mechanism necessary for migrating other Java EE objects from one JVM to another.
Web Application Class Loader
Servlet containers that are part of a Java EE product should not allow the application to override Java SE or Java EE platform classes, such as those in java.* and javax.* namespaces, that either Java SE or Java EE do not allow to be modified.
Web Application Environment
JavaEE defines a naming environment that allows applications to easily access resources and external information without explicit knowledge of how the external information is named or organized.
As servlets are an integral component type of Java EE technology, provision has been made in the Web application deployment descriptor for specifying information allowing a servlet to obtain references to resources and enterprise beans. The deployment elements that contain this information are:
■ env-entry ■ ejb-ref ■ ejb-local-ref ■ resource-ref ■ resource-env-ref ■ service-ref ■ message-destination-ref ■ persistence-context-ref ■ persistence-unit-ref
The developer uses these elements to describe certain objects that the Web
application requires to be registered in the JNDI namespace in the Web container at runtime.
The requirements of the Java EE environment with regard to setting up the environment are described in Chapter 5 of the Java EE Specification.
Servlet containers that are part of a Java EE technology-compliant implementation are required to support this syntax. Consult the Java EE Specification for more details. This type of servlet container must support lookups of such objects and calls made to those objects when performed on a thread managed by the servlet container. This type of servlet container should support this behavior when performed on threads created by the developer, but are not currently required to do so. Such a requirement will be added in the next version of this specification. Developers are cautioned that depending on this capability for application-created threads is not recommended, as it is non-portable.
JNDI Name for Web Module Context Root URL
The Java EE Platform Specification defines a standardized global JNDI namespace and a series of related namespaces that map to various scopes of a Java EE application. These namespaces can be used by applications to portably retrieve
Chapter 15 Requirements related to other Specifications 175
The name of the pre-defined java.net.URL resource for the context root of a web application has the following syntax:
java:global[/<app-name>]/<module-name>!ROOT in the global namespace and
java:app/<module-name>!ROOT in the application-specific namespace.
Plese see section EE 8.1.1 (Component creation) and EE 8.1.2 (Application assembly) for the rules to determine the app name and module name
The <app-name> is applicable only when the webapp is packaged within a .ear file.
The java:app prefix allows a component executing within a Java EE application to access an application-specific namespace. The java:app name allows a module in an enterprise application to reference the context root of another module in the same enterprise application. The <module-name> is a required part of the syntax for java:app url.
The above URL can then be used within an application as follows:
If a web application is deployed standalone with module-name as myWebApp.The URL can then be injected into another web module as follows:
CODE EXAMPLE 15-1
@Resource(lookup=“java:global/myWebApp!ROOT”) URL myWebApp;
When packaged in an ear file named myApp it can be used as follows:
CODE EXAMPLE 15-2
@Resource(lookup=“java:global/myApp/myWebApp!ROOT”) URL myWebApp;
This section details the additional security requirements for web containers when included in a product that also contains EJB, JACC and or JASPIC. The following sections call out the requirements
Propagation of Security Identity in EJB™
CallsA security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJB container. In other scenarios, web containers are required to allow web users that are not known to the web container or to the EJBcontainer to make calls:
■ Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet.
■ Application code may be the sole processor of signon and customization of data based on caller identity.
In these scenarios, a web application deployment descriptor may specify a run-as
element. When it is specified, the container must propagate the security identity for any call from a servlet to the EJB layer in terms of the security role name defined in the run-as element. The security role name must be one of the security role names defined for the web application.
For web containers running as part of a Java EE platform, the use of run-as elements must be supported both for calls to EJB components within the same Java EE application, and for calls to EJB components deployed in other Java EE
Container Authorization Requirements
In a Java EE product or in a product that includes support for Java Authorization Contracts for Containers (JACC, i.e, JSR 115), all Servlet containers MUST implement support for JACC. The JACC Specification is available for download at
Container Authentication Requirements
In a Java EE product, or a product that includes support for The Java Authentication SPI for Containers (JASPIC, i.e, JSR 196), all Servlet containers MUST implement the Servlet Container Profile of the JASPIC specification. The JASPIC Specification is available for download at http://www.jcp.org/en/jsr/detail?id=196
Chapter 15 Requirements related to other Specifications 177
This section details the deployment descriptor, packaging and deployment
descriptor processing requirements of a Java EE technology compliant container and products that include support for JSP and or Web Services.
Deployment Descriptor Elements
The following additional elements exist in the Web application deployment
descriptor to meet the requirements of Web containers that are JSP pages enabled or part of a Java EE application server. They are not required to be supported by containers wishing to support only the servlet specification:
■ Syntax for declaring resource references (env-entry, ejb-ref, ejb-local-ref, resource-ref, resource-env-ref)
■ Syntax for specifying the message destination (message-destination, message- destination-ref)
■ Reference to a Web service (service-ref)
■ Reference to a Persistence context (persistence-context-ref)
■ Reference to a Persistence Unit (persistence-unit-ref)
The syntax for these elements is now held in the JavaServer Pages specification version 2.2, and the Java EE specification.
Packaging and Deployment of JAX-WS
Web containers may choose to support running components written to implement a Web service endpoint as defined by the JAX-RPC and/or JAX-WS specifications. Web containers embedded in a Java EE conformant implementation are required to support JAX-RPC and JAX-WS web service components. This section describes the packaging and deployment model for web containers when included in a product which also supports JAX-RPC and JAX-WS.
JSR-109 [http://jcp.org/jsr/detail/109.jsp] defines the model for packaging a
Web service interface with its associated WSDL description and associated classes. It defines a mechanism for JAX-WS and JAX-RPC enabled Web containers to link to a component that implements this Web service. A JAX-WS or JAX-RPC Web service implementation component uses the APIs defined by the JAX-WS and/or JAX-RPC
specifications, which defines its contract with the JAX-WS and/or JAX-RPC enabled Web containers. It is packaged into the WAR file. The Web service developer makes a declaration of this component using the usual <servlet> declaration.
JAX-WS and JAX-RPC enabled Web containers must support the developer in using the Web deployment descriptor to define the following information for the endpoint implementation component, using the same syntax as for HTTP Servlet components using the servlet element. The child elements are used to specify endpoint information in the following way:
■ the servlet-name element defines a logical name which may be used to locate this endpoint description among the other Web components in the WAR
■ the servlet-class element provides the fully qualified Java class name of this endpoint implementation
■ the description element(s) may be used to describe the component and may be displayed in a tool
■ the load-on-startup element specifies the order in which the component is initialized relative to other Web components in the Web container
■ the security-role-ref element may be used to test whether the authenticated user is in a logical security role
■ the run-as element may be used to override the identity propagated to EJBs called by this component
Any servlet initialization parameters defined by the developer for this Web
component may be ignored by the container. Additionally, the JAX-WS and JAX-RPC enabled Web component inherits the traditional Web component mechanisms for defining the following information:
■ mapping of the component to the Web container’s URL namespace using the servlet mapping technique
■ authorization constraints on Web components using security constraints
■ the ability to use servlet filters to provide low-level byte stream support for manipulating JAX-WS and/or JAX-RPC messages using the filter mapping technique
■ the time out characteristics of any HTTP sessions that are associated with the component
■ links to Java EE objects stored in the JNDI namespace
All of the above requirements can be met using the pluggability mechanism defined in Section 8.2, “Pluggability” on page 8-65.