jump to navigation

Web Applications in Java August 16, 2005

Posted by Coolguy in Servlets/Jsp, Web Applications.
trackback
  • A Web application is a collection of servlets, HTML pages, classes, and other resources that make up a complete application on a Web server.
  • By default, an instance of a Web application must run on one VM at any one time. This behavior can be overridden if the application is marked as
    “distributable” via its deployment descriptor. An application marked as
    distributable must obey a more restrictive set of rules than is required of a normal Web application.
  • The servlet container must enforce a one to one correspondence between a Web application and a ServletContext.A ServletContext object provides a servlet with its view of the application.
  • A Web application may consist of the following items:
    • Servlets
    • JSP Pages
    • Utility Classes
    • Static documents (HTML, images, sounds, etc.)
    • Client side Java applets, beans, and classes
    • Descriptive meta information that ties all of the above elements together
  • A Web application exists as a structured hierarchy of directories.
  • The root of this hierarchy serves as the document root for files that are part of the application.
  • For example, for a Web application with the context path /catalog in a Web container, the index.html file at the base of the Web application hierarchy can be served to satisfy a request from /catalog/index.html
  • Web containers must reject Web applications defining a context path could cause potential conflicts in this URL namespace. This may occur,
    for example, by attempting to deploy a second Web application with the same context path.
  • Requests are matched to resources in a case-sensitive manner
  • A special directory exists within the application hierarchy named “WEB-INF “. This directory contains all things related to the application that aren’t in the document root of the application.
  • The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may
    be served directly to a client by the container.Any requests from the client to access the resources in WEB-INF/directory must be returned with a SC_NOT_FOUND (404) response.
  • The contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext
  • If the Application Developer needs access, from servlet code, to application specific configuration information that he does not wish to be exposed directly to the Web client, he may place it under this directory.
  • The contents of the WEB-INF directory are:
    • The /WEB-INF/web.xml deployment descriptor.
    • The /WEB-INF/classes/directory for servlet and utility classes. The classes in this directory must be available to the application class loader.
    • The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the Web application. The Web application class loader must be able to load classes from any of these archive files.
  • The Web application class loader must load classes from the WEB-INF/classes directory first, and then from library JARs in the WEB-INF/lib directory.
  • The following is a listing of all the files in a sample Web application:
    /index.html
    /howto.jsp
    /feedback.jsp
    /images/banner.gif
    /images/jumping.gif
    /WEB-INF/web.xml
    /WEB-INF/lib/jspbean.jar
    /WEB-INF/classes/com/mycorp/servlets/MyServlet.class
    /WEB-INF/classes/com/mycorp/util/MyUtils.class
  • Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools.
  • The Web application deployment descriptor includes the following types of configuration and deployment information:
    • ServletContext Init Parameters
    • Session Configuration
    • Servlet/JSP Definitions
    • Servlet/JSP Mappings
    • MIME Type Mappings
    • Welcome File list
    • Error Pages
    • Security
  • When a number of applications make use of the same code or resources, they will typically be installed as library files in the container. These files are often common or standard APIs that can be used without sacrificing portability.
  • Files used only by one or a few applications will be made available for access as part of the Web application. The container must provide a directory for these libraries.
  • E:g In tomcat, for classes and resources that must be shared across all web applications, place unpacked classes and resources under $CATALINA_BASE/shared/classes, or place JAR files containing those classes and resources under $CATALINA_BASE/shared/lib. $CATALINA_HOME/common/classes contains additional classes that are made visible to both Tomcat internal classes and to all web applications
  • The application developer depending on such an extension or extensions must provide a META-INF/MANIFEST.MF entry in the WAR file listing all extensions needed by the WAR.
  • The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource
  • A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application.
  • To allow developers to customize the appearance of content returned to a Web client when a servlet generates an error, the deployment descriptor defines a list of error page descriptions.
  • The syntax allows the configuration of resources to be returned
    by the container either when a servlet or filter calls sendError on the response for specific status codes, or if the servlet generates an exception or error that propagates to the container.
  • If the sendError method is called on the response, the container consults the list of error page declarations for the Web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry.
  • A servlet or filter may throw the following exceptions during processing of a request:
    • runtime exceptions or errors
    • ServletExceptions or subclasses thereof
    • IOExceptions or subclasses thereof
  • The Web application may have declared error pages using the exception-
    type element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exception-type element.
  • Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception-type.Same goes with error-page declarations using the status-code element.
  • If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500.
  • Web Application developers can define an ordered list of partial URIs called welcome files in the Web application deployment descriptor.
  • If a Web container receives a valid partial request, the Web container must examine the welcome file list defined in the deployment descriptor.
  • If no matching welcome file is found in the manner described, the container may handle the request in a manner it finds suitable. For some configurations this may mean returning a directory listing or for others returning a 404 response.
  • 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
  • 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.
  • Servlet containers that are part of a J2EE technology-compliant implementation are required to support this syntax.
  • When a web application is deployed into a container, the following steps must be performed, in this order, before the web application begins processing client requests.
    • Instantiate an instance of each event listener identified by a
    <listener>
    element in the deployment descriptor.
    • For instantiated listener instances that implement ServletContextListener , call the contextInitialized() method.
    • Instantiate an instance of each filter identified by a
    <filter>
    element in the deployment descriptor and call each filter instance’s init()method.
    • Instantiate an instance of each servlet identified by a
    <servlet>element that includes a
    <load-on-startup>
    element in the order defined by the load-on-startup element values, and call each servlet instance’s init()method.
Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: