EE5 Web Applications
Java EE technology-compliant containers are required to provide a mechanism by which a deployer can learn what JAR files containing resources and code are available for the Web application. Providing such the mechanism is recommended, but not required for the containers that are not part of Java EE technology-compliant implementation. The containers should provide a convenient procedure for editing and configuring library files or extensions.
EE5 Web Appli Environment
Java EE 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:
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 5 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.
EE5 Security
Propagation of Security Identity in EJBTM Calls: A 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 EJB container 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 applications.
EE5 Deployment
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:
- jsp-config
- Syntax for looking up JNDI objects (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)
Packaging and Deployment of JAX-WS Components: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 JavaEE conformant implementation are required to support JAX-RPC and JAX-WS web service components. This section describes the packaging and deployment model for such JAX-RPC and JAX-WS Web component implementations.
Rules for Processing the Deployment Descriptor:The containers and tools that are part of Java EE technology-compliant implementation are required to validate the deployment descriptor against the XML schema for structural correctness. The validation is recommended, but not required for the web containers and tools that are not part of a Java EE technology compliant implementation.
EE5 Annotations and Resource Injection
- @Resource Annotation
- @Resources Annotation
- @InjectionComplete Annotation
- @EJB Annotation
- @WebServiceRef Annotation
- @DeclaresRoles
- @RunAs Annotation
Servlet Container
The servlet container is a part of a Web server or application server that provides the network services over which requests and responses are sent, decodes MIME-based requests, and formats MIME-based responses. A servlet container also contains and manages servlets through their lifecycle.
support protocol
All servlet containers must support HTTP as a protocol for requests and responses, but additional request/response-based protocols such as HTTPS (HTTP over SSL) may be supported. The required versions of the HTTP specification that a container must implement are HTTP/1.0 and HTTP/1.1. Because the container may have a caching mechanism described in RFC2616(HTTP/1.1), it may modify requests from the clients before delivering them to the servlet, may modify responses produced by servlets before sending them to the clients, or may respond to requests without delivering them to the servlet under the compliance with RFC2616.
security restrictions
A servlet container may place security restrictions on the environment in which a servlet executes. In a Java Platform, Standard Edition (J2SE, v.1.3 or above) or Java Platform, Enterprise Edition (Java EE, v.1.3 or above) environment, these restrictions should be placed using the permission architecture defined by the Java platform. For example, high-end application servers may limit the creation of a Thread object to insure that other components of the container are not negatively impacted. J2SE 5.0 is the minimum version of the underlying Java platform with which servlet containers must be built.
The Servlet Interface
The Servlet interface is the central abstraction of the Java Servlet API. All servlets implement this interface either directly, or more commonly, by extending a class that implements the interface. The two classes in the Java Servlet API that implement the Servlet interface are GenericServlet and HttpServlet. For most purposes, Developers will extend HttpServlet to implement their servlets.
- Request Handling Methods
- Number of Instances
- Servlet Life Cycle
Servlet Context Interface
The ServletContext interface defines a servlet’s view of the Web application within which the servlet is running. The Container Provider is responsible for providing an implementation of the ServletContext interface in the servlet container. Using the ServletContext object, a servlet can log events, obtain URL references to resources, and set and store attributes that other servlets in the context can access. A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext.
- Scope of a ServletContext Interface
- Initialization Parameters
- Context Attributes
- Resources
- Multiple Hosts and Servlet Contexts
- Reloading Considerations
The Request
The request object encapsulates all information from the client request. In the HTTP protocol, this information is transmitted from the client to the server in the HTTP headers and the message body of the request.
Request data encoding
Currently, many browsers do not send a char encoding qualifier with the Content-Type header, leaving open the determination of the character encoding for reading HTTP requests. The default encoding of a request the container uses to create the request reader and parse POST data must be “ISO-8859-1” if none has been specified by the client request. However, in order to indicate to the developer in this case the failure of the client to send a character encoding, the container returns null from the getCharacterEncoding method. If the client hasn’t set character encoding and the request data is encoded with a different encoding than the default as described above, breakage can occur. To
remedy this situation, a new method setCharacterEncoding(String enc) has been added to the ServletRequest interface. Developers can override the character encoding supplied by the container by calling this method. It must be called prior to parsing any post data or reading any input from the request. Calling this method once data has been read will not affect the encoding.
The Response
The response object encapsulates all information to be returned from the server to the client. In the HTTP protocol, this information is transmitted from the server to the client either by HTTP headers or the message body of the request.
Filtering
Filters are Java components that allow on the fly transformations of payload and header information in both the request into a resource and the response from a resource.A filter is a reusable piece of code that can transform the content of HTTP requests, responses, and header information. Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource. Filters can act on dynamic or static content. For the purposes of this chapter, dynamic and static content are referred to as Web resources. Among the types of functionality available to the developer needing to use
filters are the following:
- The accessing of a resource before a request to it is invoked.
- The processing of the request for a resource before it is invoked.
- The modification of request headers and data by wrapping the request in customized versions of the request object.
- The modification of response headers and response data by providing customized versions of the response object.
- The interception of an invocation of a resource after its call.Actions on a servlet, on groups of servlets, or static content by zero, one, or more filters in a specifiable order.
Sessions
The Hypertext Transfer Protocol (HTTP) is by design a stateless protocol. To build effective Web applications, it is imperative that requests from a particular client be associated with each other. Many strategies for session tracking have evolved over time, but all are difficult or troublesome for the programmer to use directly.
Web Applications
A Web application is a collection of servlets, HTML pages, classes, and other resources that make up a complete application on a Web server. The Web application can be bundled and run on multiple containers from multiple vendors.
Application Lifecycle Events
The application events facility gives the Web Application Developer greater control over the lifecycle of the ServletContext and HttpSession and ServletRequest, allows for better code factorization, and increases efficiency in managing the resources that the Web application uses.
Mapping Requests to Servlets
The mapping techniques described in this chapter are required for Web containers mapping client requests to servlets.
Security
Web applications are created by Application Developers who give, sell, or otherwise transfer the application to a Deployer for installation into a runtime environment. Application Developers need to communicate to Deployers how the security is to be set up for the deployed application. This is accomplished declaratively by use of the deployment descriptors mechanism.
Deployment Descriptor
This chapter specifies the JavaTM Servlet Specification version 2.5 requirements for Web container support of deployment descriptors. The deployment descriptor conveys the elements and configuration information of a Web application between Application Developers, Application Assemblers, and Deployers. For Java Servlets v.2.4 and greater, the deployment descriptor is defined in terms of an XML schema document. For backwards compatibility of applications written to the 2.2 version of the API, Web containers are also required to support the 2.2 version of the deployment descriptor. For backwards compatibility of applications written to the 2.3 version of the API, Web containers are also required to support the 2.3 version of the deployment descriptor. The 2.2 and 2.3 versions are defined in the appendices.
