[펌] web.xml 사용법

Understanding web.xml Files | 펌글	2004/11/23 11:22
http://blog.naver.com/joy7600/40008189699
http://www.shockrave.com/v1/handlers/index.cfm?id=19399&method=full   Understanding web.xml Files by Matt Horn Technical Writer Macromedia Deployment Descriptor Overview Deployment descriptors are text-based XML files whose elements describe how to deploy and assemble components into a specific environment. They also contain information about the components that can specify settings not contained in the code of the components themselves, such as initialization parameters and security settings. This section explains the various types of deployment descriptors found in J2EE-compliant systems and then focuses on the web.xml file, the web component deployment descriptor. Types of deployment descriptors Deployment descriptors come in several flavors as defined by the J2EE specification. There are three major deployment descriptors, which correspond to three major pieces of the J2EE: J2EE application deployment descriptor. J2EE applications contain one or more J2EE modules and one J2EE application deployment descriptor. The J2EE application deployment descriptor is stored as /META-INF/application.xml and is defined in the J2EE specification. Its major function is to point to the modules within the application. J2EE applications are typically stored and deployed as enterprise application archive (EAR) files. EJB module deployment descriptor. EJB modules contain one or more EJB components. The EJB module deployment descriptor is stored as /META-INF/ejb-jar.xml and is defined in the EJB specification. Its major function is to define and configure EJBs. EJB modules are typically stored and deployed as Java archive (JAR) files. Web module deployment descriptor. Web modules contain one or more web components (such as servlets, JSPs, or HTML files). The web module deployment descriptor is stored as /WEB-INF/web.xml and is defined in the Servlet specification. Its major function is to define the web component settings. Web modules are typically stored and deployed as web application archive (WAR) files. This article does not address the J2EE application client module and J2EE connector module, which also have their own deployment descriptors. Furthermore, Tag Library Descriptor (TLD) files which describe custom JSP tag libraries are not discussed. The following illustration shows two web modules, app1.war and app2.war, each containing an assortment of web components (such as JSPs, and servlets) as well as static web files (HTML files and GIFs), within a J2EE application. It also shows an EJB module with EJB components (app_ejbs.jar). Notice that just as each web and EJB module has its own deployment descriptor, so does the J2EE application. Why you need deployment descriptors Deployment descriptors relate installation and configuration information about applications to the application servers. They can also be used to convey information about the application to other people involved in the development process. If you want to create an application that can be deployed without the headache of manually configuring its components, then packaging it as a WAR, JAR, or EAR file is the best approach. Each of these files requires a deployment descriptor. Overlapping elements The following bulleted lists are meant to show the overlap of deployment descriptor elements. Common elements in all descriptors (web.xml, application.xml, and ejb- jar.xml): Icons Description Display name Elements in only web.xml and ejb-jar.xml deployment descriptors: Naming environment entries EJB references Connection factory references Security elements Elements in application.xml deployment descriptor only: Module descriptions Security roles Elements in web.xml deployment descriptor only: Servlet definitions Servlet mappings Error pages Form-based authentication configuration Elements in ejb-jar.xml deployment descriptor only: Transaction elements Persistence elements As you can see, there can be overlapping of elements in the deployment descriptors. Each of the modules have their own common elements such as descriptions, icons and display names. While these elements share element names and syntax, it is important to remember that they affect only the module whose deployment descriptor they are in. However, sometimes the modules define elements that interact with other module's elements. For example, the application.xml, ejb-jar.xml and web.xml files can all define security roles. It is the role of the application assembler to make sure that the descriptors complement one another rather than provide contradictory configuration information. For complete descriptions of the various XML files and their allowed values, you can view the DTDs in the module specifications. The elements of the web.xml file are described in detail in "web.xml Elements". The rest of this article provides information on the web application deployment descriptor file. For information on the EJB and J2EE deployment descriptors, refer to their respective specifications. Introduction to the web.xml File The web.xml file is used by the J2EE application server during deployment of a web module. It describes the web components used by that web module, environment variables, and security requirements. This information is stored as /WEB-INF/web.xml. For example, the default application's deployment descriptor might be stored as /usr/jrun/servers/default/default-app/WEB-INF/web.xml. You must add a web.xml deployment descriptor to any WAR file you want to deploy as a web application. You can then add your web module to a J2EE application, which has its own deployment descriptor (application.xml) in addition to the web module's web.xml. Who creates web.xml files JRun and the web component creator share in the creation of the web.xml deployment descriptor. Some but not all of the settings in the web.xml file can be created or edited programmatically by using JMC panels. For example, there is currently no panel to write user/role/group information to the web.xml file. For detailed information on which elements in a web.xml file can be defined by JMC panels, review the descriptions in the following sections. A table in third part of this series lists all the primary elements and shows which JMC panel defines that element. web.xml Elements The web.xml file can define the following information, as defined by the web application deployment descriptor data type definition (DTD) in the Servlet specification: Note the following syntax rules for a DTD: * Specify this element as many times as necessary (zero or more). This element is optional. ? Specify this element one time only. This element is optional. + Specify this element one or more times. This element is required if its super-element is used. Note: All web application deployment descriptors must begin with the following DOCTYPE declaration: The web.xml file contains the following types of elements: web-app element application elements servlet elements security elements environment variables EJB references These elements are described in the next two parts of this three-part series. The second installment discusses the types of elements contained in the web.xml file. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. Click here to read the next installment.   Understanding the web.xml Deployment Descriptor, Part 2 This is the second installment of a three installment series, and describes the syntax of web.xml files. This second installment has two parts. The continuation of this second installment can be viewed here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. web-app element <web-app>web.xml elements</web-app> <web-app> The web-app element wraps all other elements in the web.xml file. Each web.xml file contains a single web-app element, which is the root of the deployment descriptor and wraps all other elements in the file. Application elements Application elements define attributes that apply to an entire web application. General application elements General application elements allow you to specify a description and application name. When you create an application using the Create An Application panel in the JMC, you cannot set the general elements described in this section. You can set them in the Edit An Application panel or use a text or XML editor and edit the web.xml file directly. <description>description</description>? <display-name>name</display-name>? <description>description</description>? Provides a description of the web application. Define this element in the Application Description field on the Edit An Application panel of the JMC. <display-name>name</display-name>? Provides a short web application name. This element is intended for use in graphical programming tools. You define this element in the Application Display Name field on the Edit An Application panel of the JMC. Icon Icon elements are used in graphical programming tools to represent the web application. Application-level icon elements cannot be defined in the JMC. You can specify them by editing the web.xml file using a text editor or an XML editor. <icon>? <large-icon>file path</large-icon>? <small-icon>file path</small-icon>? </icon> <icon>? Defines an icon. <Large-icon>? Location within the web application of a 32x32 GIF or JPEG file containing an icon image. <Small-icon>? Location within the web application of a 16x16 GIF or JPEG file containing an icon image. Context-param* Context-param elements define application-level parameters. These parameters are available to servlets through the ServletContext object. You can also think of the servlet context as the web application container environment. You can define context-param elements in the JMC, as described below. <context-param>* <param-name>name</param-name> <param-value>value</param-value> <description>description</description>? </context-param> <context-param>* Defines a context parameter. <param-name> Specifies the parameter name. You define this element through the Variable Name field on the Application Variables panel in the JMC. <param-value> Specifies the parameter value. You define this element through the Variable Value field on the Application Variables panel in the JMC. <Description> Specifies the parameter description. This parameter cannot be set in the JMC. You can specify it by editing the web.xml file using a text editor or an XML editor. For more information on the variables available to the components in a servlet container environment, refer to "Environment Variables". Welcome-file-list? The welcome-file-list element contains welcome-file elements, which specify one or more files to be used as the default welcome file (such as index.htm). You typically define welcome files through the JMC, using the File Settings panel for the web application (in the JMC, these are known as default documents). <welcome-file-list>? <welcome-file>file name</welcome-file>+ </welcome-file-list> <welcome-file-list>? Contains one or more welcome-file elements. <welcome-file>+ Specifies a default welcome file. Error-page* The error-page element maps an HTTP error code or a Java exception to a file. JRun displays this file upon encountering the error code or exception type. This element cannot be set in the JMC. You can specify it by editing the web.xml file using a text editor or an XML editor. For more information on how error pages are used, refer to Developing Applications with JRun. <error-page>* <error-code>HTTP error code</error-code> <exception-type>Java exception class</exception-type> <location>location</location> </error-page> <error-page>* Contains elements that define an HTTP error code or Java exception. <error-code> Specifies an HTTP error code. You specify either error-code or exception-type; you cannot specify both. <exception-type> Specifies a Java exception class. You specify either error-code or exception-type; you cannot specify both. <location> Specifies the location of the error-page in the web application. Session-config* The session-config element defines the session-timeout parameter for the web application. You can access this value through the getMaxInactiveInterval method of the HttpSession object. You define this element through the Session Timeout(min) field on the web Application Session panel in the JMC. Note that getMaxInactiveInterval returns a value in seconds while the session-timeout element is in minutes; for example, if you set session-timeout to 5, getMaxInactiveInterval returns 300. <session-config>* <session-timeout>timeout in minutes</session-timeout>? </session-config> <session-config>* Contains the session-timeout parameter. <session-timeout>? Specifies the session timeout interval in minutes. Servlet-mapping* The servlet-mapping element specifies the servlet that JRun invokes when it encounters the associated URL pattern. <servlet-mapping>* <servlet-name>name</servlet-name> <url-pattern>mapping pattern</URL-pattern> </servlet-mapping> <servlet-mapping>* Contains servlet mapping elements. <servlet-name> Specifies the registered servlet name (also known as the alias), as defined in the JMC or the servlet element. You define this element through the Virtual Path/Extension field on the Servlet URL Mappings panel in the JMC. <URL-pattern> Specifies a URL pattern. When a URL that matches URL-pattern is encountered, JRun invokes the associated servlet. You define this element through the Servlet Invoked field on the Servlet URL Mappings panel in the JMC. Mime-mapping* The mime-mappings element contains one or more extension/mime-type pairs, each of which associates a file extension with a MIME type. <mime-mapping>* <extension>extension</extension> <mime-type>mime type</mime-type> </mime-mapping> <mime-mapping>* Contains an extension/mime-type pair. <extension> Specifies a file extension. You define this element through the MIME Type Extension field on the MIME Type Mappings panel in the JMC. <mime-type> Specifies the MIME type associate with the extension. You define this element through the MIME Type field on the MIME Type Mappings panel in the JMC. For example, if you are creating a WAP applications, you might add the following MIME mappings: <mime-mapping> <extension>wml</extension> <mime-type>text/vnd.wap.wml</mime-type> </mime-mapping> <mime-mapping> <extension>wbmp</extension> <mime-type>image/vnd.wap.wbmp</mime-type> </mime-mapping> Taglib* The taglib element provides information on a tag library that is used by JSP pages within a web application. You cannot define the taglib element through the JMC. You can specify it by editing the web.xml file using a text editor or an XML editor. <taglib>* <taglib-uri>uri</taglib-uri> <taglib-location>location</taglib-location> </taglib> <taglib>* Contains elements that associate a taglib URI with a physical location. <taglib-uri> Specifies a URI that JSP pages use to identify the tag library in the taglib directive. For example, /eistaglib. <taglib-location> Specifies the location of the tag library's TLD file. For example, /WEB-INF/tld/eistaglib.tld. Resource-ref* The resource-ref* element declares a web application's reference to an external resource. You cannot define the resource-ref element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <resource-ref>* <description>description</description>? <res-ref-name>resource factory reference name</res-ref-name> <res-type>java class</res-type> <res-auth>CONTAINER or SERVLET</res-auth> </resource-ref> <resource-ref>* Contains elements that describe an external reference. <Description>? Specifies a brief description. <res-ref-name> Specifies the resource factory reference name. <res-type> Specifies the Java class of the data source. <res-auth> Indicates that the application performs a resource login programmatically (SERVLET) or JRun signs on automatically using principal mapping information provided by the deployer (CONTAINER). Servlet elements Servlet elements define servlets and their usage. You typically define servlet settings through the JMC. The servlet element has the following general form: <servlet>* sub-elements </servlet> This is the second installment of a three installment series, and describes the syntax of web.xml files. This second installment has two parts. The continuation of this second installment can be viewed here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files.   Understanding the web.xml Deployment Descriptor, Part 2 (continued) This is the continuation of the second installment of a three part series, and describes the syntax of web.xml files. The first part of the second installment can be found here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. The following sections describe the contents of the servlet element: General servlet elements Init-param* Load-on-startup? Security-role-ref* General servlet elements <icon>? <large-icon>file path</large-icon>? <small-icon>file path</small-icon>? </icon> <servlet-name>name</servlet-name> <display-name>name</display-name>? <description>description</description>? <servlet-class>fully qualified class name</servlet-class> <jsp-file>file name</JSP-file> <icon>? For more information on the icon element, refer to "Icon". You define these elements in the Large Icon and Small Icon fields on the Servlet Definitions panel of the JMC. Note that you cannot define the application-level icons in the JMC. <Servlet-name> Specifies the registered name of the servlet. Other servlets and JSP pages reference the servlet using either this name or its class name. Define this element in the Name field of the Servlet Definitions panel of the JMC. <Display-name>? Provides a short servlet name. Intended for use in graphical programming tools. Define this element in the Display Name field on the Servlet Definitions panel of the JMC. <Description>? Provides a description of the servlet. You define this element in the Description field on the Servlet Definitions panel of the JMC. <servlet-class> Specifies the fully qualified class name for the servlet. A servlet element can contain either servlet-class or JSP-file; it cannot contain both. Define this element in the Class Name field on the Servlet Definitions panel of the JMC. <JSP-file> Specifies the full path to a JSP file within the web application. A servlet element can contain either servlet-class or JSP-file; it cannot contain both. You define this element in the Class Name field on the Servlet Definitions panel of the JMC. Init-param* The init-param element defines servlet-level parameters. You typically define servlet parameters through the JMC. <init-param>* <param-name>name</param-name> <param-value>value</param-value> <description>description</description>? </init-param> <init-param>* Contains elements that define a servlet-level initialization parameter. <param-name> Specifies the parameter name. Define this element in the Init Arguments field on the Servlet Definitions panel of the JMC. <param-value> Specifies the parameter value. Define this element in the Init Arguments field on the Servlet Definitions panel of the JMC. <Description>? Specifies a description for the initialization parameter. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. For more information on the variables available to the components in a servlet container environment, refer to "Environment Variables". Load-on-startup? The presence of this element indicates that JRun loads the servlet at startup. Define this element using the Servlet Preload Order dialog box from the Servlet Definitions panel in the JMC. For more information, refer to the JRun Setup Guide. <load-on-startup>optional sequence</load-on-startup>? <load-on-startup>? Specifies that JRun loads the servlet at startup time. You can optionally enclose a positive integer to indicate a relative loading sequence. JRun loads lower integers before higher integers. For example, the following code indicates that FredServlet gets loaded first, followed by TomServlet. <servlet> <servlet-name>FredServlet</servlet-name> ... <load-on-startup>1</load-on-startup> ... </servlet> <servlet> <servlet-name>TomServlet</servlet-name> ... <load-on-startup>2</load-on-startup> ... </servlet> Security-role-ref* The security-role-ref element declares a security role reference in the servlet code. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <security-role-ref>* <description>description</description>? <role-name>name</role-name> <role-link>role from security-role</role-link> </security-role-ref> <security-role-ref>* Contains a security role reference. <Description>? Specifies a brief description. <role-name> Specifies the security role reference used within the servlet's code. <role-link> Specifies the related role name, as defined in the user data store. Security elements Web.xml security elements specify the resources to be secured and the roles authorized to access secure resources. You cannot define these elements through the JMC. You specify them by editing the web.xml file using a text editor or an XML editor. For more information on the security elements in the web.xml file, refer to Developing Applications with JRun. Security-constraint* The security-constraint element associates security constraints with one or more web resource collections and has the following general form: <security-constraint>* sub-elements </security-constraint> The following discussions describe the contents of the security-constraint element: web-resource-collection+ Auth-constraint? web-resource-collection+ The web-resource-collection+ element identifies the resources and HTTP methods to which a security constraint applies. <web-resource-collection>+ <web-resource-name>name</web-resource-name> <description>description</description>? <URL-pattern>pattern</URL-pattern>* <http-method>method</HTTP-method>* </web-resource-collection> <web-resource-collection>+ Contains elements that identify the resources and HTTP methods to which a security constraint applies. <web-resource-name> Specifies the name of the web resource collection. <Description>? Specifies a description for the web resource collection. <URL-pattern>* Identifies the resources to be secured (for example, /store/*). <HTTP-method>* Specifies the HTTP method for which the security constraint applies. If you do not specify this element, JRun applies the security constraint to all methods. Auth-constraint? The auth-constraint element specifies the roles that can access the web resource collection. <auth-constraint>? <description>description</description>? <role-name>name</role-name>* </auth-constraint> <auth-constraint>? Contains elements that specify the roles that can access the collection. <Description>? Specifies a description for the constraint. <Role-name>* Specifies the roles that can access the resources affected by web-resource-collection. Login-config? The login-config element specifies authentication instructions. For complete examples of the login-config element, refer to Developing Applications with JRun. <login-config>? <auth-method>BASIC or FORM</auth-method>? <realm-name>name</realm-name>? <form-login-config>sub-elements</form-login-config>? </login-config> <login-config>? Contains elements that specify authentication instructions. <auth-method>? Specifies the user validation method. This can be either HTTP challenge/response (BASIC) or an HTML login form (FORM). If you specify FORM, you must specify the form-login-config element. <realm-name>? Specifies the realm name to use in HTTP BASIC authorization. If you omit this element, JRun uses the name of the JRun server hosting the application as the realm name. <form-login-config>? Specifies a login page and an error page through the following sub-elements: form-login-page specifies the path to a page containing a login form. form-error-page specifies the path to a page containing an error form. Environment entries The env-entry element declares application-level environment variables. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <env-entry>* <description>description</description>? <env-entry-name>name</env-entry-name> <env-entry-value>value</env-entry-value>? <env-entry-type>type</env-entry-type> </env-entry> <env-entry>* Contains elements that define the application's environment entry. <Description>? Specifies a description for the environment entry. <env-entry-name> Specifies the name of the environment entry. <env-entry-value>? Specifies the value of the environment entry. <env-entry-type> Specifies the fully-qualified Java type of env-entry-value. Legal values are as follows: java.lang.Boolean java.lang.String java.lang.Integer java.lang.Float java.lang.Double For more information on the variables available to the components in a servlet container environment, refer to "Environment Variables". EJB references The ejb-ref element declares a reference to an Enterprise JavaBean. You cannot define this element through the JMC. You specify it by editing the web.xml file using a text editor or an XML editor. <EJB-ref>* <description>description</description>? <ejb-ref-name>name</EJB-ref-name> <ejb-ref-type>type</EJB-ref-type> <home>home interface</home> <remote>remote interface</remote> <ejb-link>ejb name</ejb-link>? </ejb-ref> <ejb-ref>* Contains elements that declare an EJB. <Description>? Specifies a description for the EJB. <ejb-ref-name> Specifies the JNDI name that servlets use to get a reference to the EJB. <ejb-ref-type> Specifies the Java class type of the referenced EJB. <home> Specifies the fully qualified name of the EJB's home interface. <remote> Specifies the fully qualified name of the EJB's remote interface. <ejb-link>? Specifies that the reference is linked to an EJB in an encompassing J2EE application package. The value of this element must be the ejb-name of an EJB in the J2EE application package. Unsupported elements The following list outlines web.xml elements that are named in the Java Servlet Specification, version 2.2 but are not supported by JRun: distributable user-data-constraint This is the continuation of the second installment of a three part series, and describes the syntax of web.xml files. The first part of the second installment can be found here. The first installment introduced the basics of deployment descriptors. The third installment discusses using environment variables and creating web.xml files, and shows complete examples of web.xml files. Understanding the web.xml Deployment Descriptor, Part 3 This is the third part of a three-part series. This installment discusses using environment variables, creating web.xml files, and shows complete examples of web.xml files. The first installment introduced the basics of deployment descriptors. The second installment covered the syntax of web.xml files. Environment Variables There are two kinds of environment variables available to components within web modules that you can set in the web.xml deployment descriptor. These are: Component-specific. These parameters can only be accessed from a single web component (such as a servlet or JSP) within the module. In the deployment descriptor, they are tagged as the init-param sub-elements inside the servlet element. Container-specific. These variables can be accessed from all web components within the servlet container environment. They can be tagged as either env-entry or context-param elements in the deployment descriptor. These environment variables are explained in the sections that follow. Component-specific parameters Component-specific parameters are set in the init-param element of the web.xml deployment descriptor. This element must be within the servlet element. You can define values and names for any number of parameters. For example, you could define a component-specific parameter in a deployment descriptor as follows: <servlet> <init-param> <param-name>EmailAddress</param-name> <param-value>sales@Macromedia.com</param-value> </init-param> </servlet> Component-specific parameters are accessible through the ServletContext object's getInitParameter() method. You could write code in that specific web component that extracts the value of this parameter as follows: String addy = this.getInitParameter("EmailAddress"); Container-specific environment variables Container-specific environment variables can be used to provide configuration information to all web components (such as servlets and JSPs) within a web application or servlet container environment. There are two available container-specific environment variables: Container parameters Application environment variables Both types of variables can be accessed from any web component in the servlet container environment, however, they are accessed in different ways, described in the sections that follow. Container parameters Container parameters are set in the context-param element of the web.xml deployment descriptor. You can define names and values for any number of parameters. Accessing container parameters only returns strings. For example, you could define a container parameter in a deployment descriptor as follows: <context-param> <param-name>footerPage</param-name> <param-value>/data/foot11-00.html</param-value> </context-param> Container parameters are accessible through the ServletContext object's getInitParameter() method. You could write code in that specific web component that extracts the value of this parameter as follows: ServletContext context = this.getServletContext(); String footer = context.getInitParameter("footerPage"); While this appears very similar to the component-specific parameters, remember that these parameters can be accessed from any web component within the servlet container environment. Application environment variables Application environment variables are set in the env-entry element of the web.xml deployment descriptor. You can define names and values for any number of parameters. Accessing application environment variables can return several types of objects. With the env-entry-type sub-element, you can reference one of the following types of objects: Boolean String Integer Double Float The env-entry-type sub-element provides a built-in mechanism for validating the object's type. This validation takes place at deployment time. As an example, you could define an application environment variable in a deployment descriptor as follows: <env-entry> <env-entry-name>headerPage</env-entry-name> <env-entry-value>/data/head11-00.html</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry> Application environment variables are accessed in the java:comp/env context through a JNDI lookup rather than from a ServletContext object. You could write code in any web component within the servlet container environment that extracts the value of this application environment variable as follows: InitialContext context = new InitialContext(); String header = (String) context.lookup("java:comp/env/headerPage"); The JNDI lookup method expects the type specified by the <env-entry-type> element and will throw an exception if the returned value isn't of that type. Creating a web.xml File The web.xml file is created both by the JMC and the programmer since the JMC does not have panels that can make all the changes. The easiest way to create a web.xml file is to let JRun do most of the work. The general process of creating a web.xml file follows. 1 Create an application in the JMC using the Create An Application panel. This creates a skeleton web.xml file for the application. 2 Use the Edit An Application panel to add the description and display-name elements to your web.xml deployment descriptor. 3 Use JMC panels to make any other changes to the web application settings. The following table can be used as a general guideline showing which elements can be defined by which JMC panel. For more information on which sub-elements can be defined by the JMC, refer to the specific element's description beginning in the below list.   web.xml element JMC panel icon Cannot be defined using the JMC display-name Edit An Application description Edit An Application distributable Cannot be defined using the JMC context-param Application Variables* servlet Servlet Definitions* servlet-mapping Servlet URL Mappings session-config web Application Session mime-mapping MIME Type Mappings welcome-file-list File Settings error-page Cannot be defined using the JMC taglib Cannot be defined using the JMC resource-ref Cannot be defined using the JMC security-constraint Cannot be defined using the JMC login-config Cannot be defined using the JMC security-role Cannot be defined using the JMC env-entry Cannot be defined using the JMC ejb-ref Cannot be defined using the JMC * Some, but not all, sub-elements can be set in the JMC panel. 4 Use a text editor or XML editor to define elements in the web.xml file that cannot be defined by the JMC. Examples of web.xml Files This section provides a basic example of a web.xml file and a security example. For more web.xml file examples, refer to the Java Servlet Specification, version 2.2. Basic example The following example web.xml file contains basic information. <web-app> <display-name>JRun Demo</display-name> <description>JRun Demo</description> <session-config> <session-timeout>30</session-timeout> </session-config> <mime-mapping> <extension> txt </extension> <mime-type> text/plain </mime-type> </mime-mapping> <mime-mapping> <extension> html </extension> <mime-type> text/html </mime-type> </mime-mapping> <welcome-file-list> <welcome-file> index.html </welcome-file> </welcome-file-list> </web-app> Security example The following web.xml file contains entries that enable authentication. <web-app> <display-name>Security Default</display-name> <description>Default application for testing security</description> <session-config> <session-timeout>30</session-timeout> </session-config> <mime-mapping> <extension> txt </extension> <mime-type> text/plain </mime-type> </mime-mapping> <mime-mapping> <extension> html </extension> <mime-type> text/html </mime-type> </mime-mapping> <error-page> <error-code>401</error-code> <location>/Unauthorized.html</location> </error-page> <error-page> <error-code>403</error-code> <location>/Forbidden.html</location> </error-page> <login-config> <auth-method> FORM </auth-method> <realm-name> Sales </realm-name> <form-login-config> <form-login-page> /login.html </form-login-page> <form-error-page> /loginerror.html </form-error-page> </form-login-config> </login-config> <security-constraint> <web-resource-collection> <web-resource-name>SalesInfo</web-resource-name> <url-pattern>/servlet/Sn*</URL-pattern> <http-method>GET</HTTP-method> <HTTP-method>POST</HTTP-method> <description>Sales Info Resource</description> <auth-constraint> <role-name>manager</role-name> <description>Managers only</description> </auth-constraint> </web-resource-collection> </security-constraint> <welcome-file-list> <welcome-file> index.jsp </welcome-file> <welcome-file> index.html </welcome-file> </welcome-file-list> <servlet> <servlet-name> SecureSnoop </servlet-name> <servlet-class> SecureSnoop </servlet-class> <security-role-ref> <role-name> MGR </role-name> <role-link> manager </role-link> </security-role-ref> </servlet> </web-app> This installment discussed using environment variables, creating web.xml files, and showed complete examples of web.xml files. The first installment introduced the basics of deployment descriptors. The second installment covered the syntax of web.xml files.