Section A.1. Web Components (web.xml)
A.1. Web Components (web.xml)Web components are deployed using a web.xml deployment descriptor. The high-level descriptor layout for web deployment descriptors is shown in Figure A-1. In all the diagrams in this section, deployment elements that were introduced in the Servlet 2.4 specification are labeled with a "2.4" indicator. All other elements were present in the 2.3 (and possibly earlier) version of the Servlet specification. The format for an empty web.xml file is shown in Example A-1. Example A-1. Web deployment descriptor header<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> . . . </web-app> The example shows the XML schema for the Servlet 2.4 deployment descriptor being referenced from the default location on the java.sun.com server. To reference the Servlet 2.3 DTD instead (e.g., if you are using a J2EE 1.3 application server like JBoss 3.x or a Servlet 2.3 container like Tomcat 4.x), you should start your deployment descriptor with the following DOCTYPE element and no schema reference: <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> . . . </web-app> A.1.1. General Cross-Component SettingsThe elements shown in Figure A-2 are used for deployment settings that apply across the web components in the web archive. The elements in this section of the web deployment descriptor are demonstrated in the annotated descriptor segment shown in Example A-2. Figure A-2. General web archive deployment settings Example A-2. Annotated general deployment settings<web-app . . . > <!-- Display name for the web application. --> <display-name>name</display-name> <!-- Description of the web application. --> <description>desc</description> <!-- Icon for representing the web application visually in tools, such as IDEs and app management tools. --> <icon> <small-icon>/icons/my-small-icon.jpg</small-icon> <large-icon>/icons/my-large-icon.jpg</large-icon> </icon> <!-- The presence of this element indicates to the web container that this web application can be safely distributed in clustered servlet containers. It may also trigger additional runtime checks by the container, for things like Serializable data in Session parameters. --> <distributable/> <!-- These elements declare context parameters that are made available to all servlets in this module, using the getInitParameter( ) method on their ServletContexts. --> <context-param> <!-- Description of the context parameter. --> <description>The default color for the sky</description> <!-- Name of the init parameter. --> <param-name>sky-color</param-name> <!-- Value of the init parameter. The value is always retrieved by the servlet as a String (the return type of the getInitParameter( ) method). --> <param-value>blue</param-value> </context-param> <!-- Defines the session parameters for all components in this module. The only config parameter allowed as of Servlet 2.4 is the session timeout period. --> <session-config> <!-- Defines the length of time a session will live without any activity by the user. The time is given in minutes. --> <session-timeout>30</session-timeout> </session-config> <jsp-config> <!-- Each taglib element specifies the mapping of a custom tag library URI (used in a taglib directive in a JSP) to a Tag Library Description TLD file within the web archive that should be used to define the tags. --> <taglib> <!-- The URI serves as an identifier used in a JSP file to load a given tag library. The URI in the JSP taglib directive is matched to this taglib-uri element, and the corresponding TLD file is loaded for the JSP. --> <taglib-uri>http://my.jsp.app/taglibs/commerce</taglib-uri> <!-- The location, relative to the root of the web application context, of the TLD file for the tag library. --> <taglib-location>WEB-INF/taglibs/commerce.tld</taglib-location> </taglib> <!-- This element defines groups of JSP pages within the web archive, and various parameters for handling of the JSPs in the group. --> <jsp-property-group> <!-- The URL pattern that defines the JSP group. --> <url-pattern>/admin</url-pattern> <!-- If set to true, any JSP EL expressions in the JSPs will not be parsed. --> <el-ignored>false</el-ignored> <!-- Specifies the character encoding of the pages. This value must match any pageEncoding directives used in the JSP pages themselves. Valid character encoding values can be found at www.iana.org. --> <page-encoding>US-ASCII</page-encoding> <!-- If true, any page scripting elements in the JSPs in this group will be rejected as invalid. --> <scripting-invalid>false</scripting-invalid> <!-- Indicates that all pages in the URL pattern are to be interpreted as XML-based JSP pages, rather than depending on other factors, like file suffixes. --> <is-xml>true</is-xml> <!-- If present, the named page element (HTML or JSP) is included, as an include directive, in the beginning of every JSP in the group. --> <include-prelude>/my/company-header.jsp</include-prelude> <include-prelude>/my/admin-header.jsp</include-prelude> <!-- If present, the named page element (HTML or JSP) is included, as an include directive, at the end of each JSP in the group. --> <include-coda>/my/admin-footer.jsp</include-coda> <include-coda>/my/company-footer.jsp</include-coda> </jsp-property-group> </jsp-config> <!-- These elements are used to define a mapping from a file extension to a MIME type. This can be used for special data types that the web components will generate for the user or to override the settings of the underlying HTTP server. --> <mime-mapping> <!-- The file extension (suffix) to be mapped. Examples are "gif", "txt", "xls". --> <extension>txt</extension> <!-- The MIME type to be broadcast to web clients for files with the above extension. --> <mime-type>text/plain</mime-type> </mime-mapping> <!-- An ordered list of welcome files, used to automatically resolve client requests for URLs that resolve to directories rather than specific JSP pages or servlets. The files listed here will be searched for in order within the target directory, and if one is found in the directory, it will be served to the user. --> <welcome-file-list> <!-- Each welcome-file element contains a single filename. --> <welcome-file>index.jsp</welcome-file> <welcome-file>index.html</welcome-file> </welcome-file-list> <!-- Each error-page element contains a mapping from an HTTP error code or Java exception type, to the URL for an error page. When the error or exception is encountered, the client will be redirected to the error page. --> <error-page> <!-- Each error-page element must contain either an error-code specification that contains a valid HTTP error code (e.g., "500"), or an exception-type element that contains the fully qualified class name for a Java exception (e.g., "java.lang.NumberFormatException"). --> <error-code>404</error-code> <!-- The URL of the error page the user should be sent to if the HTTP error code or Java exception is encountered. The location has to be a relative path within the web archive file and starts with a '/'. --> <location>/my/error/page.html</location> </error-page> <error-page> <exception-type>my.app.exception</exception-type> <location>/my/error/page2.html</location> </error-page> <!-- A list of mappings of locales to character encodings. Requests that are associated with a specific locale will have the responses encoded using the character sets specified below. --> <locale-encoding-mapping-list> <!-- Specify that requests tagged with the China/Tiawan locale are encoded using the Big5 character set. --> <locale-encoding-mapping> <locale>zh_TW</locale> <encoding>Big5</encoding> </locale-encoding-mapping> <!-- Specify that any English locales (US, UK, etc.) are encoded using UTF-8 --> <locale-encoding-mapping> <locale>en_US</locale> <encoding>UTF-8</encoding> </locale-encoding-mapping> </locale-encoding-mapping-list> . . . </web-app> A.1.2. Web Component DeclarationsWeb components (servlets and JSPs) are declared and configured in this section of the deployment descriptor. Figure A-3 shows an overview of the elements present in this segment of the descriptor. Example A-3 shows sample web component declarations , annotated with descriptive comments. Figure A-3. Web component declarations Example A-3. Annotated web component declarations<web-app . . .> . . . <!-- Each web component in this module is declared with a servlet element. This element is used for both servlets and JSP files. JSP files do not strictly require a servlet element, since they have a default URL mapping (their relative path within the web archive). But they do need an entry if any other configuration is needed for the JSP. --> <servlet> <!-- Description of component. --> <description>desc</description> <!-- Display name for the component, used in tools. --> <display-name>name</display-name> <!-- Icon used to represent the web component in tools. --> <icon> <small-icon>/icons/my-small-servlet-icon.jpg</small-icon> <large-icon>/icons/my-large-servlet-icon.jpg</large-icon> </icon> <!-- Name to be used to refer to this component elsewhere in this deployment descriptor. --> <servlet-name>MyServlet</servlet-name> <!-- A declaration of either the fully qualified servlet class name (servlet-class) or the absolute path to the JSP file within the web archive (jsp-file). --> <!-- role="strong"><jsp-file>/my/jsp/file.jsp</jsp-file> --> <servlet-class>my.servlet.classname</servlet-class> <!-- Declare initialization parameters that will be accessible to this component through the getInitParameter( ) method on its ServletConfig object. --> <init-param> <!-- Description of the init parameter. --> <description>desc</description> <!-- Name of the init parameter. --> <param-name>name</param-name> <!-- Value of the init parameter. The value is always retrieved by the servlet as a String (the return type of the getInitParameter( ) method). --> <param-value>value</param-value> </init-param> <!-- Used to indicate whether and when this web component should be loaded when the enclosing web application is started. The value of this element is a single integer that is used to determine the order in which components will be loaded. A negative integer allows the container to load the component whenever it wants during startup. A non-negative integer puts the component in a load order, lower- numbered components are loaded first. Components with the same value are loaded in an undetermined order by the container. --> <load-on-startup>42</load-on-startup> <!-- Indicates a user role that should be used to run this web component. If this element is not provided, the role(s) of the client will be applied while the request is processed. --> <run-as> <!-- Description of the run-as role. --> <description>desc</description> <!-- The role this component should always be run as. The role name should match the name of a security-role element in this deployment descriptor. --> <role-name>name</role-name> </run-as> <!-- Declare security roles referenced in this web component. These roles are made available at runtime through the HttpServletRequest.isUserInRole( ) method. --> <security-role-ref> <!-- A text description of the role. --> <description>desc</description> <!-- The role name as used in the web component code. --> <role-name>Administrator</role-name> <!-- Normally, the role-name must have a corresponding security-role defined in the web.xml file. Alternatively, you can link the role-name to another security-role entry using the role-link element. --> <role-link>admin</role-link> </security-role-ref> </servlet> <!-- These elements are used to define mappings from URLs to servlet components defined above. For example, to map a filter to everything in the "images" directory: "/images/*"; to map a filter to all PDF files: "*.pdf"; to map to a specific document or component, use the full URL, e.g., "/docs/intro.html".--> <servlet-mapping> <!-- The name of the servlet/JSP component. This name must match the servlet-name of a servlet element defined above. --> <servlet-name>MyServlet</servlet-name> <!-- The URL pattern that is to be mapped to the servlet/JSP. The pattern uses the same syntax as that used for filter mappings. For example, to map a servlet to everything in the "tools" directory: "/tools/*", to map a servlet to all PDF files: "*.pdf"; to map to a specific URL, use the full URL, e.g., "/tools/login". --> <url-pattern>/admin/login</url-pattern> </servlet-mapping> . . . </web-app> A.1.3. Web Handler DeclarationsYou can define two kinds of web handlers in the deployment descriptor, filters and listeners. Web filters are executed prior to the delivery of requests to specific web components or documents. Listeners are notified of events during the runtime management of the components, such as the creation and deletion of user sessions. The deployment elements relevant to web handlers are shown in Figure A-4. Example A-4 shows sample web handler declarations annotated with descriptive comments. Figure A-4. Web handler deployment elements Example A-4. Annotated web handler declarations<web-app . . .> . . . <!-- Declare a filter that can be applied to incoming requests for servlets or static URLs. Filters are mapped to servlets and URLs using filter-mapping elements, below. --> <filter> <!-- Description of filter. --> <description>Description</description> <!-- Display name, to represent the filter in tools. --> <display-name>Filter display name</display-name> <!--Icon for representing the filter in tools. --> <icon> <small-icon>/icons/my-small-filter-icon.jpg</small-icon> <large-icon>/icons/my-large-filter-icon.jpg</large-icon> </icon> <!-- Name for the filter, to be used in filter-mappings. --> <filter-name>MyFilter</filter-name> <!-- The fully qualified class name of the filter. The class must implement the javax.servlet.Filter interface. --> <filter-class>my.filter.classname</filter-class> <!-- Define initialization parameters. These parameters are accessed by the filter using the getInitParameter( ) method on its FilterConfig. --> <init-param> <!-- Description of the init parameter. --> <description>desc</description> <!-- Name of the init parameter. --> <param-name>param-name</param-name> <!-- Value of the init parameter. The value is always retrieved by the filter as a String (the return type of the getInitParameter( ) method). --> <param-value>param-value</param-value> </init-param> </filter> <!-- These elements are used to determine which filters to apply to client requests for given URLs. These filter mappings are checked in order to determine all of the filters applicable to a given resource. All of the matching filters make up an ordered chain of filters that are called in sequence before the actual servlet or URL resource is accessed. --> <filter-mapping> <!-- Name of the filter to be applied. The name must match the filter-name for a filter element above. --> <filter-name>MyFilter</filter-name> <!-- Specify the servlet/JSP name or URL(s) the filter should be applied to. Either a url-pattern or servlet-name must be provided. The value of the url-pattern follows the rules of servlet mappings. For example, to map a filter to everything in the "images" directory: "/images/*"; to map a filter to all PDF files: "*.pdf"; to map to a specific URL, use the full URL, e.g., "/docs/intro.html". If a servlet-name is used, it has to match the name in a servlet-mapping element, above. --> <url-pattern>/filterurl</url-pattern> <!-- <servlet-name>name</servlet-name> --> </filter-mapping> <!-- These elements declare listeners that should be applied to the web application. Listeners must implement one of the EventListener interfaces defined in the javax.servlet and javax.servlet.http packages. --> <listener> <!-- The fully qualified class name of the listener. --> <listener-class>my.listener.classname</listener-class> </listener> . . . </web-app> A.1.4. Security ConfigurationThe deployment information includes the configuration of security constraints on the application. These include the declaration of abstract authorization roles, specifications of security levels (access and data protection) on subsets of the web application, and the manner in which users should be authenticated. Figure A-5 shows the elements in this section of the deployment descriptor. Example A-5 shows sample security constraints annotated with descriptive comments. Figure A-5. Security constraint elements Example A-5. Annotated security constraints<web-app . . .> . . . <!-- Each security-role element declares a security role used by web components in this archive. Each named role must be mapped to a physical group/identity within the runtime security environment of the web container/J2EE server.--> <security-role> <!-- A description of the role. --> <description>My admin role, used for super-users</description> <!-- Name of the role, as used in the rest of this descriptor. --> <role-name>admin</role-name> </security-role> <!-- Define security constraints on subsets of the application. The application subset is defined by the web-resource-collection element, and the constraints are defined in the auth-constraint and user-data-constraint elements. --> <security-constraint> <!-- Display name for the constraint. --> <display-name>Security setting for admin area</display-name> <!-- Define the domain of this constraint, using one or more URL patterns, plus optional HTTP method filters. --> <web-resource-collection> <!-- Name for the resource. --> <web-resource-name>Admin-pages</web-resource-name> <!-- Description of the subset of the application. --> <description>The admin area of the application</description> <!-- One or more URL patterns that define the set of the application being constrained. --> <url-pattern>/admin/*</url-pattern> <url-pattern>/admin-docs/*</url-pattern> <!-- One or more HTTP method filters, that further refine the constraint to apply to only specific types of requests. --> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <!-- Define the role(s) that are allowed to access this subset of the application. --> <auth-constraint> <!-- Role name, must match an entry in the security-role section --> <role-name>admin</role-name> </auth-constraint> <!-- Declare the degree to which data should be protected as it is transmitted from the server to the client. --> <user-data-constraint> <!-- Description of the constraint. --> <description>Ensure admin ops are encrypted</description> <!-- Set the transport guarantee to one of NONE (no special handling required), INTEGRAL (data must not be changed in transit), and CONFIDENTIAL (data must not be observable by outside parties during transit). --> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <!-- This element is used to configure how authentication should be handled by the web application. --> <login-config> <!-- The type of authentication the web application should use. Allowed values are "BASIC" (for HTTP Basic authentication using the web server), "FORM" (to use your own login forms), "DIGEST" (more secure but less-supported web server login), and "CLIENT-CERT" (to use public-key authentication between the client and the server). --> <auth-method>FORM</auth-method> <!-- When BASIC authentication is chosen, this element indicates which realm, as defined in the web server and/or application server, to use for authentication. --> <realm-name>app-users</realm-name> <!-- If FORM authentication is chosen, this element provides the information on how form logins will be handled. --> <form-login-config> <!-- The absolute location, as a path within the war file, of the page to be used for form-based login authentication. --> <form-login-page>/admin/login</form-login-page> <!-- The error page, where users will be sent when authentication fails. --> <form-error-page>/auth/error.jsp</form-error-page> </form-login-config> </login-config> . . . </web-app> A.1.5. Component ReferencesIf your web components depend on other components (such as EJBs or web services), you declare these component references in the deployment descriptor to allow the container a chance to verify the availability of these dependencies. Figure A-6 shows the deployment elements used for component references. Example A-6 shows sample component references, annotated with descriptive comments. Figure A-6. Component reference elements Example A-6. Annotated component references<web-app . . .> . . . <!-- An ejb-ref element is used to specify a remote reference to an EJB used by web components in this archive. The ejb-local-ref element is used to declare a reference using local EJB interfaces. The presence of an ejb-ref entry in a client's deployment descriptor is simply a placeholder that indicates that the client refers to this EJB using the indicated name, and therefore the expected EJB must be available. At deploy time, if the EJB named here can't be resolved in the environment, then the deployment tools can catch this and raise a deployment-time error, avoiding a runtime error. --> <ejb-ref> <!-- Description of the EJB's use. --> <description>The cart EJB</description> <!-- The JNDI name used by the application client to look up the home interface for this EJB. The name is relative to the java:comp/env context. The J2EE specification. recommends (but does not require) preceding JNDI references for EJBs with "ejb/". This name has to resolve, eventually, to a real EJB home of the type described in this ejb-ref. This means that the name used here has to be mapped (using the J2EE server's native tools) to a JNDI name that is the same as the deployed JNDI name of an EJB component, or an ejb-link element has to be given here that links this name directly to an EJB component in the same application archive (ear). --> <ejb-ref-name>ejb/ShoppingCartEJB</ejb-ref-name> <!-- The type of EJB referenced. Allowed values are "Entity" or "Session" (message-driven beans have no home interfaces). --> <ejb-ref-type>Session</ejb-ref-type> <!-- The fully qualified class name of the remote home interface. --> <home>my.ejb.ShoppingCartHome</home> <!-- The fully qualified class name of the remote client interface --> <remote>my.ejb.ShoppingCart</remote> <!-- This element can be used to link this EJB reference to another EJB component in the same enclosing application jar file. The value of the link is the name of the EJB, as specified in the ejb-name element in its deployment descriptor. You can also prepend the linked name with a relative path to the ejb-jar file of the target EJB, followed by a '#', e.g., "../ejbs/dataEJBs.jar#Person". This can be useful when there are multiple EJBs with the same ejb-name in the same application. If no ejb-link element is provided, then the EJB reference will simply be resolved directly to the JNDI name implied by the ejb-ref-name, e.g., "java:comp/env/ejb/name". An EJB home of the expected type should be deployed to that name in order for the reference to be resolved correctly. --> <ejb-link>ShoppingCart-remote</ejb-link> </ejb-ref> <!-- Similar to the ejb-ref element, except this reference uses local client and home interfaces, for those cases where the EJB is running within the same application server instance --> <ejb-local-ref> <!-- JNDI reference name. --> <ejb-ref-name>ejb/ShoppingCartEJB-local</ejb-ref-name> <!-- Type of EJB being referenced. --> <ejb-ref-type>Session</ejb-ref-type> <!-- Local home interface class name. --> <local-home>my.ejb.ShoppingCartLocalHome</local-home> <!-- Local client interface. --> <local>my.ejb.ShoppingCartLocal</local> <!-- Link this reference to an EJB in the same application archive. --> <ejb-link>ShoppingCart-local</ejb-link> </ejb-local-ref> <!-- Declare a dependence on a JAX-RPC interface to a SOAP web service. At a minimum you need to specify a reference name and the JAX-RPC interface to the service, but you can also specify a number of other details. --> <service-ref> <description>Neat web service</description> <display-name>Reference to web service X</display-name> <icon> <small-icon>/icons/my-small-icon.jpg</small-icon> <large-icon>/icons/my-large-icon.jpg</large-icon> </icon> <!-- JNDI name used by the web components to reference the JAX-RPC interface to the service. --> <service-ref-name>service/MyWebService</service-ref-name> <!-- The interface/class that the service interface is expected to satisfy. This can be a custom interface, perhaps one mapped from the service WSDL, or it can simply be the JAX-RPC Service interface, which all service interfaces must implement. The container is responsible for verifying that the service interface actually implements the interface given here. --> <service-interface>javax.xml.rpc.Service</service-interface> <!-- The path (within the web archive) to the WSDL for the service. --> <wsdl-file>WEB-INF/wsdl/myservice.wsdl</wsdl-file> <!-- The path (within the web archive) to the JAX-RPC mapping file, specifying how to map between XML entities and Java entities for the service. --> <jaxrpc-mapping-file>WEB-INF/myservice-mapping.xml</jaxrpc-mapping-file> <!-- The qualified name for the service within the WSDL file --> <service-qname>com.mypartner:cool-service</service-qname> <!-- Declare that the web components require a specific port from the service to be mapped to a JAX-RPC interface. --> <port-component-ref> <!-- The interface that the mapped port must implement. --> <service-endpoint-interface>my.service.endpoint </service-endpoint-interface> <!-- You can optionally link this port reference to a JAX-RPC port component within the same application archive. The link value should match a port-component-name in a deployed webservices.xml deployment descriptor in one of the web or EJB archives in this application. --> <port-component-link>MyServicePort</port-component-link> </port-component-ref> <!-- The handler element is used to specify handlers for this service. --> <handler> <!-- A name for the handler. --> <handler-name>MySOAPHandler</handler-name> <!-- The full class name of the handler. The class must implement the javax.xml.rpc.handler.Handler interface --> <handler-class>my.soap.handler</handler-class> <!-- Specify initialization parameters, passed into the handler's init( ) method as part of the HandlerInfo --> <init-param> <!-- Name of the parameter. --> <param-name>param1</param-name> <!-- Value of the parameter. --> <param-value>value1</param-value> </init-param> <!-- The SOAP actor role that the handler should play as it processes the SOAP request. --> <soap-role>urn:my-service</soap-role> <!-- The qualified name of the SOAP header to be processed by the handler. --> <soap-header>com.partner:header1</soap-header> <!-- Name of the WSDL port for the handler.--> <port-name>service-port-x</port-name> </handler> </service-ref> . . . </web-app> A.1.6. Resources and Environment EntriesWhen web components require various external resources and environment entries, they are declared in the deployment descriptor using the elements shown in Figure A-7. The resources that can be declared include resource factories that generate connections to services (e.g., a JDBC DataSource that generates Connections to databases or JMS ConnectionFactory objects that generate Connections to JMS messaging services), resources themselves (e.g., URLs or JMS destinations), or basic environment data (e.g., string or numeric values, or basic data objects). All of the entities declared in this section of the descriptor are accessed at runtime through JNDI lookups and therefore need to be present in the server's JNDI service when the application is deployed. Example A-7 shows sample resource declarations and environment entries, annotated with descriptive comments. Figure A-7. Elements for resource and environment entries Example A-7. Annotated resource and environment entries<web-app . . .> . . . <!-- A reference to a resource factory used by the web components. A resource factory is used to create connections to a managed service. Exampes of factories configurable using a resource-ref are JDBC DataSources, JMS ConnectionFactories, and JavaMail Sessions. You can also configure your own custom factories. The presence of a resource-ref entry in a deployment descriptor is simply a placeholder that indicates that the client refers to this resource using the indicated name, and therefore the expected resource must be deployed in the application server at the specified JNDI name. At deploy time, if the resource named here can't be resolved in the environment, then the container can catch this and raise a deployment-time error, avoiding a runtime error. --> <resource-ref> <!-- Description of the resource factory. --> <description>JMS connection factory for message service</description> <!-- JNDI name, relative to java:comp/env, used to look up the resource factory. --> <res-ref-name>jms/notify-connection</res-ref-name> <!-- Class of the resource factory. --> <res-type>javax.jms.QueueConnectionFactory</res-type> <!-- Authorization model for the factory, either Container or Application. --> <res-auth>Container</res-auth> <!-- This entry specifies whether connections obtained from the resource factory are shareable (Shareable) or not (Unshareable). --> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> <!-- A reference to a general managed object used by the web components. A resource-env-ref was used prior to J2EE 1.4 to declare JMS destinations. In J2EE 1.4, JMS destinations are declared in the message-destination and message-destination-ref elements below. --> <resource-env-ref> <!-- Description of the env. resource. --> <description>Message queue for notifications</description> <!-- JNDI name, relative to java:comp/env, used to look up the resource in the environment. --> <resource-env-ref-name>jms/notify-queue</resource-env-ref-name> <!-- Java type of the resource. --> <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type> </resource-env-ref> <!-- Used to create environment entries that the application client can access at runtime through JNDI in the java:comp/env context. --> <env-entry> <!-- Description of the environment entry. --> <description>Message notification alert threshold</description> <!-- JNDI name, relative to java:comp/env, used to look up the env entry. --> <env-entry-name>email-alert-threshold</env-entry-name> <!-- The Java type of the entry value. The only types allowed for application client entries are Boolean, Byte, Character, String, Short, Integer, Long, Float, Double. --> <env-entry-type>java.lang.Integer</env-entry-type> <!-- The value of the entry. The string used here will be used to initialize an instance of the type specified in the env-entry-type element, by passing it into its constructor. --> <env-entry-value>12</env-entry-value> </env-entry> <!-- Declare names for message destinations that will be used to resolve the message destination references below. The message destinations declared here must be resolved during deployment to actual, physical JMS destinations that are appropriate for the usage declared in the corresponding message-destination-ref elements. --> <message-destination> <description>Another queue used for notifications</description> <display-name>Another notify queue</display-name> <icon> <small-icon>icons/my-small-jms-icon.jpg</small-icon> <large-icon>icons/my-large-jms-icon.jpg</large-icon> </icon> <!-- Declare a logical name for the message destination. --> <message-destination-name>my-notify-queue</message-destination-name> </message-destination> <!-- Declare a reference to a message destination, as it is used within the components in this archive. This maps a JNDI name to one of the message destinations declared above, and specifies the type of destination expected and how the components use the destination. --> <message-destination-ref> <!-- Specify the JNDI name (relative to java:comp/env) used by the components to reference this destination. --> <message-destination-ref-name >jms/notify-queue2</message-destination-ref-name> <!-- Specify the type of destination expected (Queue or Topic). --> <message-destination-type>javax.jms.Queue</message-destination-type> <!-- Specify how the components use the destination, in terms of message direction (Consumes, Produces, or ConsumesProduces).--> <message-destination-usage>Produces</message-destination-usage> <!-- A link to a message destination, using its logical name. --> <message-destination-link>my-notify-queue</message-destination-link> </message-destination-ref> . . . </web-app> |
Java Enterprise in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596101422
EAN: 2147483647
EAN: 2147483647
Year: 2004
Pages: 269
Pages: 269
Authors: Jim Farley, William Crawford
- Step 1.1 Install OpenSSH to Replace the Remote Access Protocols with Encrypted Versions
- Step 3.3 Use WinSCP as a Graphical Replacement for FTP and RCP
- Step 3.4 Use PuTTYs Tools to Transfer Files from the Windows Command Line
- Step 4.7 Using Public Key Authentication for Automated File Transfers
- Appendix - Sample sshd_config File