805 OCPJP 6 Questions 788 SCJP 5 questions 650 OCPJWCD 5 questions 600 OCAJP 7 questions 610 OCPJP 7 questions 510 Upgrade to OCPJP 7 questions 900 Java J2EE Qns

Tutorials

SCWCD : The Structure and Deployment of Web Applications

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.

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. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext, and may be exposed using the RequestDispatcher calls. Hence, 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. Since requests are matched to resource mappings in a case-sensitive manner, client requests for /WEB-INF/foo, /WEb-iNf/foo, for example, should not result in contents of the Web application located under /WEB-INF being returned, nor any form of directory listing thereof.

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. Also, any requests from the client to access the resources in WEB-INF/ directory MUST be returned with a SC_NOT_FOUND (404) response.

Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools. For example, an application for issue tracking might be distributed in an archive file called issuetrack.war.

When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools. This directory MUST NOT be directly served as content by the container in response to a Web client's request, though its contents are visible to servlet code via the getResource and getResourceAsStream calls on the ServletContext. Also, any requests to access the resources in META-INF directory must be returned with a SC_NOT_FOUND (404) response.

Tag extensions written in JSP using tag files can be placed in one of two locations. The first possibility is in the /META-INF/tags/ directory (or a subdirectory of /META-INF/tags/) in a JAR file installed in the /WEB-INF/lib/ directory of the web application. Tags placed here are typically part of a reusable library of tags that can be easily dropped into any web application.

The second possibility is in the /WEB-INF/tags/ directory (or a subdirectory of /WEB-INF/tags/) of the web application. Tags placed here are within easy reach and require little packaging. Only files with a .tag or .tagx extension are recognized by the container to be tag files.

Tag files that appear in any other location are not considered tag extensions and must be ignored by the JSP container. For example, a tag file that appears in the root of a web application would be treated as content to be served.

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/lib/jstl.jar
/WEB-INF/jsp/example-taglib.tld 
/WEB-INF/jsp/debug-taglib.tld 
/WEB-INF/jsp2/jsp2-example-taglib.tld 
/WEB-INF/tags/displayProducts.tag
/WEB-INF/tags/helloWorld.tag     
/WEB-INF/tags/panel.tag          
/WEB-INF/tags/xhtmlbasic.tag     
/WEB-INF/classes/com/mycorp/servlets/MyServlet.class
/WEB-INF/classes/com/mycorp/util/MyUtils.class


					

Construct the correct structure for each of the following deployment descriptor elements: error-page, init-param, mime-mapping, servlet, servlet-class, servlet-mapping, servlet-name, and welcome-file.

Error pages.


<!--
The error-page element contains a mapping between an error code or
exception type to the path of a resource in the web application
-->

<!ELEMENT error-page ((error-code | exception-type), location)>

					

Init parameters.

				
<!--
The init-param element contains a name/value pair as an
initialization param of the servlet
-->

<!ELEMENT init-param (param-name, param-value, description?)>

					

MIME mapping.


<!--
The mime-mapping element defines a mapping between an extension and
a mime type.
-->

<!ELEMENT mime-mapping (extension, mime-type)>

					

<!--
The extension element contains a string describing an
extension. example: "txt"
-->

<!ELEMENT extension (#PCDATA)>

					

<!--
The mime-type element contains a defined mime type. example: "text/
plain"
-->

<!ELEMENT mime-type (#PCDATA)>

					

Servlet.

				
<!--
The servlet element contains the declarative data of a
servlet.
If a jsp-file is specified and the load-on-startup element is
present, then the JSP should be precompiled and loaded.
-->

<!ELEMENT servlet (icon?, servlet-name, display-name?, description?,
	(servlet-class|jsp-file), init-param*, load-on-startup?,
	security-role-ref*)>

					

<!--
The servlet-name element contains the canonical name of the
servlet.
-->

<!ELEMENT servlet-name (#PCDATA)>

					

<!--
The servlet-class element contains the fully qualified class name
of the servlet.
-->

<!ELEMENT servlet-class (#PCDATA)>

					

<!--
The jsp-file element contains the full path to a JSP file within
the web application.
-->

<!ELEMENT jsp-file (#PCDATA)>

					

Servlet mapping.

				
<!--
The servlet-mapping element defines a mapping between a servlet and
a url pattern

-->
<!ELEMENT servlet-mapping (servlet-name, url-pattern)>

					

Welcome files.


<!--
The welcome-file-list contains an ordered list of welcome files
elements.
-->

<!ELEMENT welcome-file-list (welcome-file+)>

					

env-entry


<!--
The env-entry element contains the declaration of an application's
environment entry.
This element is required to be honored on in J2EE compliant servlet
containers.

The env-entry-type element contains the fully qualified Java type of
the environment entry value that is expected by the application
code.

The following are the legal values of env-entry-type:
java.lang.Boolean, java.lang.String, java.lang.Integer,
java.lang.Double, java.lang.Float.
-->

<!ELEMENT env-entry (description?, env-entry-name, env-entry-value?,
env-entry-type)>

					

<env-entry>
	<env-entry-name>tableName</env-entry-name>
	<env-entry-value>StockTable</env-entry-value>
	<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
					
					

ejb-ref


<!--
The ejb-ref element is used for the declaration of a reference to
an enterprise bean's home. The declaration consists of:
- an optional description
- the EJB reference name used in the code of
the web application that's referencing the enterprise bean
- the expected type of the referenced enterprise bean
- the expected home and remote interfaces of the referenced
enterprise bean
- optional ejb-link information, used to specify the referenced
enterprise bean

The ejb-ref element is used to declare a reference to an enterprise
bean.

The ejb-ref-name element contains the name of an EJB
reference. This is the JNDI name that the servlet code uses to get a
reference to the enterprise bean.

The ejb-ref-type element contains the expected type of the
referenced enterprise bean.

The ejb-ref-type element MUST be one of the following:

<ejb-ref-type>Entity</ejb-ref-type>
<ejb-ref-type>Session</ejb-ref-type>

The home element contains the fully qualified name of the EJB's
home interface

The remote element contains the fully qualified name of the EJB's
remote interface

The ejb-link element is used in the ejb-ref element to specify that
an EJB reference is linked to an EJB in an encompassing Java2
Enterprise Edition (J2EE) application package.
The value of the ejb-link element must be the ejb-name of and EJB in
the J2EE application package.
-->

<!ELEMENT ejb-ref (description?, ejb-ref-name, ejb-ref-type, home,
remote, ejb-link?)>

					

<!-- reference on a remote bean without ejb-link-->
<ejb-ref>
	<ejb-ref-name>ejb/MySessionBean</ejb-ref-name>
	<ejb-ref-type>Session</ejb-ref-type>
	<home>org.sample.beans.MySessionBeanHome</home>
	<remote>org.sample.beans.MySessionBean</remote>
</ejb-ref>

					

<!-- reference on a remote bean using ejb-link-->
<ejb-ref>
	<ejb-ref-name>ejb/EjbLinkMySessionBean</ejb-ref-name>
	<ejb-ref-type>Session</ejb-ref-type>
	<home>org.sample.beans.MySessionBeanHome</home>
	<remote>org.sample.beans.MySessionBean</remote>
	<ejb-link>MySB.jar#MySessionBean</ejb-link>
</ejb-ref>
					
					

ejb-local-ref


<!--
The ejb-local-ref element is used for the declaration of a reference
to an enterprise bean's local home. The declaration consists of:
- an optional description
- the EJB reference name used in the code of the web application
that's referencing the enterprise bean
- the expected type of the referenced enterprise bean
- the expected local home and local interfaces of the referenced
enterprise bean
- optional ejb-link information, used to specify the referenced
enterprise bean

The ejb-ref-type element contains the expected type of the
referenced enterprise bean.

The ejb-ref-type element MUST be one of the following:

<ejb-ref-type>Entity</ejb-ref-type>
<ejb-ref-type>Session</ejb-ref-type>
-->

<!ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type,
local-home, local, ejb-link?)>

					

<!-- reference on a local bean -->
<ejb-local-ref>
	<ejb-ref-name>ejb/MySBLocal</ejb-ref-name>
	<ejb-ref-type>Session</ejb-ref-type>
	<local-home>org.sample.beans.MySessionBeanLocalHome</local-home>
	<local>org.sample.beans.MySessionBeanLocal</local>
	<ejb-link>secusb.jar#Op</ejb-link>
</ejb-local-ref>
					
					

resource-ref


<!--
The resource-ref element contains a declaration of a Web
Application's reference to an external resource.

The res-auth element indicates whether the application component
code performs resource signon programmatically or whether the
container signs onto the resource based on the principle mapping
information supplied by the deployer. Must be CONTAINER or SERVLET !
-->

<!ELEMENT resource-ref (description?, res-ref-name, res-type, res-auth)>

					

<resource-ref>
	<res-ref-name>jdbc/BookDB</res-ref-name>
	<res-type>javax.sql.DataSource</res-type>
	<res-auth>Container</res-auth>
</resource-ref> 
					
					

resource-env-ref


<!--
The resource-env-ref element contains a declaration of a web
application's reference to an administered object associated with a
resource in the web application's environment. It consists of an
optional description, the resource environment reference name, and
an indication of the resource environment reference type expected by
the web application code.
-->

<!ELEMENT resource-env-ref (description?, resource-env-ref-name,
resource-env-ref-type)>

					

<resource-env-ref>
	<resource-env-ref-name>jms/Orders</resource-env-ref-name>
	<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>
					
					

Explain the purpose of a WAR file and describe the contents of a WAR file, how one may be constructed.

Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools. For example, an application for issue tracking might be distributed in an archive file called issuetrack.war. When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools. This directory must not be directly served as content by the container in response to a Web client’s request, though its contents are visible to servlet code via the getResource and getResourceAsStream calls on the ServletContext. Also, any requests to access the resources in META-INF directory must be returned with a SC_NOT_FOUND(404) response.

A WAR usually contains following resources:

  • Servlets, JavaServer Pages (JSP), Custom Tag Libraries.

  • Server-side utility classes (database beans, shopping carts, and so on).

  • Static web resources (HTML, image, and sound files, and so on).

  • Client-side classes (applets and utility classes).

The directory structure of a Web application consists of two parts. The first part is the public directory structure containing HTML/XML documents, JSP pages, images, applets, and so on. The container appropriately serves the directory's contents against incoming requests. The second part is a special WEB-INF directory that contains the following files and directories:
  • web.xml - the web application deployment descriptor.

  • Tag Library Descriptor files.

  • classes/ - a directory that contains server-side classes: servlet, utility classes, and JavaBeans components.

  • lib/ - a directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes).

  • tags/ - a directory that contains Tag files (made easily accessible to JSPs without the need to explicitly write a Tag Library Descriptor files).

The structure of the WAR files looks like this:

WEB-INF/
WEB-INF/web.xml
WEB-INF/classes/
WEB-INF/lib/
WEB-INF/tags/

					

To prepare the web application for deployment, package it in a WAR file using the following jar utility command from the top-level directory of the application:

					
jar cvf web_app.war .
					

scjp 1.5 | scjp 1.6 | scwcd 1.5
Java Certifications
www.javacertifications.net