Skip navigation.
Downloads | Product Documentation | Support

Developing Web Applications for WebLogic Server

# weblogic.xml Deployment Descriptor Elements

The following sections describe the deployment descriptor elements that you define in the `weblogic.xml` file under the root element `<weblogic-web-app>`:

- auth-filter
- charset-params
- container-descriptor
- context-root
- description
- destroy-as
- init-as
- jsp-descriptor
- preprocessor
- preprocessor-mapping
- reference-descriptor
- run-as-role-assignment
- security-permission
- security-role-assignment
- servlet-descriptor
- session-descriptor
- url-match-map
- virtual-directory-mapping
- weblogic-version
- wl-dispatch-policy

The DOCTYPE header for the `weblogic.xml` file is as follows:

>     <!DOCTYPE weblogic-web-app PUBLIC
>         "-//BEA Systems, Inc.//DTD Web Application 8.1//EN"
>         "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

You can also access the Document Type Descriptor (DTD) for `weblogic.xml` at http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd.

# description

The description element is a text description of the Web application.

# weblogic-version

The `weblogic-version` element indicates the version of WebLogic Server on which this Web application is intended to be deployed. This element is informational only and is not used by WebLogic Server.

# security-role-assignment

The `security-role-assignment` element declares a mapping between a security role and one or more principals in the realm, as shown in the following example.

>     <security-role-assignment>
>          <role-name>PayrollAdmin</role-name>
>          <principal-name>Tanya</principal-name>
>          <principal-name>Fred</principal-name>
>          <principal-name>system</principal-name>
>     </security-role-assignment>

The following table describes the elements you can define within a `security-role-assignment` element.

Element | Required Optional | Description
--- | --- | ---
`<role-name>` | Required | Specifies the name of a security role.
`<principal-name>` | Required | Specifies the name of a principal that is defined in the security realm. You can use multiple `<principal-name>` elements to map principals to a role. For more information on security realms, see Managing WebLogic Security.
`<externally-defined>` | Optional | Specifies that a particular security role is defined globally in a security realm; WebLogic Server uses this security role as the principal name, rather than looking it up in a global realm. When the security role and its principal-name mapping are defined elsewhere, this is used as an indicative placeholder.

Note: If you do not define a security-role-assignment element and its subelements, the Web application container implicitly maps the role name as a principal name and logs a warning. The EJB container does not deploy the module if mappings are not defined.

Consider the following usage scenarios for the role name is "role_xyz"

- If you map"role_xyz to user "joe" in weblogic.xml, role_xyz becomes a local role.
- If you specify role_xyz as an externally defined role, it becomes global (it refers to the role defined at the realm level).
- If you do not define a security-role-assignment element, role_xyz becomes a local role, and the Web application container creates an implicit mapping to it and logs a warning.

# run-as-role-assignment

The run-as-role-assignment element maps a run-as role name (a subelement of the servlet element) in web.xml to a valid user name in the system. The value can be overridden for a given servlet by the run-as-principal-name element in the servlet-descriptor. If the run-as-role-assignment is absent for a given role name, the Web application container chooses the first principal-name defined in the security-role-assignment.

The following table describes the elements you can define within a `run-as-role-assignment` element.

Element | Required Optional | Description
--- | --- | ---
`<role-name>` | Required | Specifies the name of a security role.
`<run-as-principal-name>` | Required | Specifies the name of a principal.

# reference-descriptor

The `reference-descriptor` element maps a name used in the Web application to the JNDI name of a server resource. The `reference-description` element contains two elements: The`resource-description` element maps a resource, for example, a DataSource, to its JNDI name. The `ejb-reference` element maps an EJB to its JNDI name.

## resource-env-description

The `resource-env-description` element maps a `resource-env-ref`, declared in the `ejb-jar.xml` deployment descriptor, to the JNDI name of the server resource it represents.

The following table describes the elements you can define within a `resource-env-description` element

Element | Required/ Optional | Description
--- | --- | ---
`<res-env-ref-name>` | Required | Specifies the name of a resource environment reference.
`<jndi-name>` | Required | Specifies a JNDI name for the resource environment reference.

.

## resource-description

The `resource-description` element is used to map the JNDI name of a server resource to an EJB resource reference in WebLogic Server.

The following table describes the elements you can define within a `resource-description` element

Element | Required/ Optional | Description
--- | --- | ---
`<res-ref-name>` | Required | Specifies the name of a resource reference.
`<jndi-name>` | Required | Specifies a JNDI name for the resource.

.

## ejb-reference-description

The following table describes the elements you can define within a `ejb-reference-description` element

Element | Required/ Optional | Description
--- | --- | ---
`<ejb-ref-name>` | Required | Specifies the name of an EJB reference used in your Web application.
`<jndi-name>` | Required | Specifies a JNDI name for the reference.

.

# session-descriptor

The `session-descriptor` element contains the session-param element, which defines attributes for HTTP sessions, as shown in the following example:

>     <session-descriptor>
>       <session-param>
>          <param-name>
>            CookieDomain
>          </param-name>
>          <param-value>
>            myCookieDomain
>          </param-value>
>       </session-param>
>     </session-descriptor>

## session-param

The following table describes the elements you can define within a `session-param` element

Element | Required/ Optional | Description
--- | --- | ---
`<param-name>` | Required | Specifies the name of the parameter.
`<param-value>` | Required | Specifies the value of the parameter.

.

The following table describes the valid session attribute names and values you can define within a `session-param` element:

Attribute Name | Default Value | Value
--- | --- | ---
`ConsoleMainAttribute` |  | If you enable Session Monitoring in the WebLogic Server Administration Console, set this attribute to the name of the session attribute you will use to identify each session that is monitored.
`CookieDomain` | Null | Specifies the domain for which the cookie is valid. For example, setting `CookieDomain` to`.mydomain.com` returns cookies to any server in the `*.mydomain.com` domain. The domain name must have at least two components. Setting a name to `*.com` or `*.net` is not valid. If not set, this attribute defaults to the server that issued the cookie. For more information, see `Cookie.setDomain()` in the Servlet specification from Sun Microsystems.
`CookieComment` | Weblogic Server Session Tracking Cookie | Specifies the comment that identifies the session tracking cookie in the cookie file. If not set, this attribute defaults to `WebLogic Session Tracking Cookie`. You may provide a more specific name for your application.
`CookieSecure` | `false` | Tells the browser to only send the cookie back over an HTTPS connection. This ensures that the cookie ID is secure and should only be used on Websites that use HTTPS. Session Cookies over HTTP no longer work if this feature is enabled. You should turn off the `URLRewritingEnabled` attribute if you intend to use this feature.
`CookieMaxAgeSecs` | -1 | Sets the life span of the session cookie, in seconds, after which it expires on the client. If the value is 0, the cookie expires immediately. The maximum value is `Integer.MAX_VALUE`, where the cookie lasts forever. If set to `-1`, the cookie expires when the user exits the browser. For more information about cookies, see Using Sessions and Session Persistence in Web Applications.
`CookieName` | `JSESSIONID` | Defines the session cookie name. Defaults to `JSESSIONID` if not set. You may set this to a more specific name for your application.
`CookiePath` | Null | Specifies the path name to which the browser sends cookies. If not set, this attribute defaults to `/` (slash), where the browser sends cookies to all URLs served by WebLogic Server. You may set the path to a narrower mapping, to limit the request URLs to which the browser sends cookies.
`CookiesEnabled` | `true` | Use of session cookies is enabled by default and is recommended, but you can disable them by setting this property to `false`. You might turn this option off to test.
`EncodeSessionIdInQueryParams` | `false` | By default, when you use the `HTTPServletResponse.encodeURL(URL)` method to encode a URL in the HTTP response, the session identifier is added to the URL as a path parameter after the`;` character in the URL. This behavior is defined by the Servlet 2.3 J2EE specification, implemented as of Version 6.1 of WebLogic Server. In Versions 6.0 and previous of WebLogic Server, however, the default behavior was to add the session identifier as a query parameter after the `?` character in the URL. To enable this old behavior, set this session parameter to `true`. Note: You typically use this parameter when WebLogic Server interacts with Web Servers that do not completely comply with the Servlet 2.3 specification.
`IDLength` | 52 | Sets the size of the session ID. The minimum value is 8 bytes and the maximum value is Integer.MAX_VALUE. If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. Also, some WAP devices have a 128-character limit on URL length (including attributes), which limits the amount of data that can be transmitted using URL re-writing. To allow more space for attributes, use this attribute to limit the size of the session ID that is randomly generated by WebLogic Server. You can also limit the length to a fixed 52 characters, and disallow special characters, by setting the WAPEnabled attribute. For more information, see URL Rewriting and Wireless Access Protocol in Developing Web Applications for WebLogic Server.
`InvalidationIntervalSecs` | `60` | Sets the time, in seconds, that WebLogic Server waits between doing house-cleaning checks for timed-out and invalid sessions, and deleting the old sessions and freeing up memory. Use this attribute to tune WebLogic Server for best performance on high traffic sites. The minimum value is every second (1). The maximum value is once a week (604,800 seconds). If not set, the attribute defaults to 60 seconds.
`JDBCConnectionTimeoutSecs` | 120 | Sets the time, in seconds, that WebLogic Server waits before timing out a JDBC connection, where x is the number of seconds between.
`PersistentStoreDir` | `session_db` | If you have set `PersistentStoreType` to `file`, this attribute sets the directory path where WebLogic Server will store the sessions. The directory path is an absolute path to the temp directory. The temp directory is specified by the context-param `javax.servlet.context.tmpdir`. Ensure that you have enough disk space to store the number of valid sessions multiplied by the size of each session. You can find the size of a session by looking at the files created in the `PersistentStoreDir`. Note that the size of each session can vary as the size of serialized session data changes. You can make file-persistent sessions clusterable by making this directory a shared directory among different servers. You must create this directory manually.
`PersistentStorePool` | `None` | Specifies the name of a JDBC connection pool to be used for persistence storage.
`PersistentStoreTable` | `wl_servlet_sessions` | Applies only when PersistentStoreType is set to jdbc. This is used when you choose a database table name other than the default.
`PersistentStoreType` | `memory` | Sets the persistent store method to one of the following options: `memory`—Disables persistent session storage. `file`—Uses file-based persistence (See also `PersistentStoreDir`, above). `jdbc`—Uses a database to store persistent sessions. (see also `PersistentStorePool`, above). `replicated`—Same as `memory`, but session data is replicated across the clustered servers. cookie—All session data is stored in a cookie in the user's browser. replicated_if_clustered—If the Web application is deployed on a clustered server, the in-effect `PersistentStoreType` will be replicated. Otherwise, `memory` is the default.
`PersistentStoreCookieName` | `WLCOOKIE` | Sets the name of the cookie used for cookie-based persistence. The `WLCOOKIE` cookie carries the session state, which should not be shared between Web applications. For more information, see Using Cookie-Based Session Persistence.
`TimeoutSecs` | 3600 | Sets the time, in seconds, that WebLogic Server waits before timing out a session, where x is the number of seconds between a session's activity. Minimum value is 1, default is 3600, and maximum value is integer MAX_VALUE. On busy sites, you can tune your application by adjusting the timeout of sessions. While you want to give a browser client every opportunity to finish a session, you do not want to tie up the server needlessly if the user has left the site or otherwise abandoned the session. This attribute can be overridden by the `session-timeout` element (defined in minutes) in `web.xml`. For more information, see session-config.
TrackingEnabled | true | Tells the Web application to keep track of the session between requests, in one of the following ways: SessionCookie URLEncoding If this is set to false, the session is not tracked, cookies coming in with the response are ignored, and the URL is not encoded.
`URLRewritingEnabled` | true | Enables URL rewriting, which encodes the session ID into the URL and provides session tracking if cookies are disabled in the browser.

# jsp-descriptor

The `jsp-descriptor` element defines attribute names and values for JSPs. You define the attributes as name/value pairs. The following example shows how to configure the `compileCommand` attribute. Enter all of the JSP configurations using the pattern demonstrated in this example:

`<jsp-descriptor>
` `<jsp-param>
` `<param-name>
` `compileCommand
` `</param-name>
` `<param-value>
` `sj
` `</param-value>
` `</jsp-param>
`</`jsp-descriptor>`

The following table describes the element you can define within a `jsp-descriptor` element

Element | Required/ Optional | Description
--- | --- | ---
`<jsp-param>` | Required | Specifies parameters for servlet JSPs. Contains the following sub-elements: <param-name> specifies a parameter name. <param-value> specifies a parameter value.

.

## JSP Attribute Names and Values

The following table describes the attribute names and values you can define within a `<jsp-param>` element.

Attribute Name | Default Value | Value
--- | --- | ---
`compileCommand` | `javac`, or the Java compiler defined for a server under the configuration /tuning tab of the WebLogic Server Administration Console | Specifies the full path name of the standard Java compiler used to compile the generated JSP servlets. For example, to use the standard Java compiler, specify its location on your system as shown below: `<param-value> /jdk130/bin/javac.exe </param-value>` For faster performance, specify a different compiler, such as IBM Jikes or Symantec `sj`.
`compileFlags` | None | Passes one or more command-line flags to the compiler. Enclose multiple flags in quotes, separated by a space. For example: `<jsp-param> <param-name>compileFlags</param-name> <param-value>"-g -v"</param-value> </jsp-param>`
`compilerclass` | None | Name of a Java compiler that is executed in WebLogic Servers's virtual machine. (Used in place of an executable compiler such as `javac` or `sj`.) If this attribute is set, the `compileCommand` attribute is ignored. Note: JSPs can be complied either in memory (in process) or by forking a new process for the compilation.

A new process is forked when the `compilerclass` is not specified and production mode is the startup mode. The in memory compilerclass option uses the compiler class used by Sun to internally compile Java files. For more information see "Precompiling JSPs" at the following URL http://e-docs.bea.com/wls/docs81/jsp/reference.html

debug

None

When set to true this adds JSP line numbers to generated class files to aid debugging.

`encoding`

Default encoding of your platform

Specifies the default character set used in the JSP page. Use standard Java character set names.

If not set, this attribute defaults to the encoding for your platform.

A JSP page directive (included in the JSP code) overrides this setting. For example:

`<%@ page contentType="text/html; charset=custom-encoding"%>`

compilerSupports
Encoding

true

When set to true, the JSP compiler uses the encoding specified with the `contentType` attribute contained in the `page` directive on the JSP page, or, if a `contentType` is not specified, the encoding defined with the `encoding` attribute in the jsp-descriptor.

When set to false, the JSP compiler uses the default encoding for the JVM when creating the intermediate .`java` file.

exactMapping

true

When true, upon the first request for a JSP the newly created JspStub is mapped to the exact request. If exactMapping is set to false, the Web application container generates non-exact url mapping for JSPs. exactMapping allows path info for JSP pages.

`keepgenerated`

`false`

Saves the Java files that are generated as an intermediary step in the JSP compilation process. Unless this attribute is set to `true`, the intermediate Java files are deleted after they are compiled.

`noTryBlocks`

`false`

If a JSP file has numerous or deeply nested custom JSP tags and you receive a `java.lang.VerifyError` exception when compiling, use this flag to allow the JSPs to compile correctly.

`packagePrefix`

`jsp_servlet`

Specifies the package into which all JSP pages are compiled.

`pageCheckSeconds`

`1`

Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.

If set to 0, pages are checked on every request. This default is preset for a development environment. If set to `-1`, page checking and recompiling is disabled.

In a production environment where cchanges to a JSP are rare, change the value of pageCheckSeconds to 60 or greater, according to your tuning requirements, or to -1 to disable page checking and recompiling.

precompile

`false`

When set to true, WebLogic Server automatically precompiles all modified JSPs when the Web application is deployed or re-deployed or when starting WebLogic Server.

precompileContinue

false

When set to true, WebLogic Server continues precompiling all modified JSPs even if some of those JSPs fail during compilation. Only takes effect when precompile is set to true.

printNulls

null

When set to false, this parameter ensures that expressions with "null" results are printed as " ".

`verbose`

`true`

When set to `true`, debugging information is printed out to the browser, the command prompt, and WebLogic Server log file.

`workingDir`

internally generated directory

The name of a directory where WebLogic Server saves the generated Java and compiled class files for a JSP.

compiler

javac

Sets the JSP compiler for use with this instance of WebLogic Server.

superclass

weblogic.servlet.jsp.JspBase

Provides a means to override the default superclass for JSPs. The JSPs are compiled as servlet classes extending from this base class.

# auth-filter

The auth-filter element specifies an authentication filter HttpServlet class.

# container-descriptor

The `<container-descriptor>` element defines general attributes for Web applications.

## check-auth-on-forward

Add the `<check-auth-on-forward/>` element when you want to require authentication of forwarded requests from a servlet or JSP. Omit the tag if you do not want to require re-authentication. For example:

>     <container-descriptor>
>         <check-auth-on-forward/>
>     </container-descriptor>

Note that the default behavior has changed with the release of the Servlet 2.3 specification, which states that authentication is not required for forwarded requests.

## redirect-with-absolute-url

The `<redirect-with-absolute-url>` element controls whether the `javax.servlet.http.HttpServletResponse.SendRedirect()` method redirects using a relative or absolute URL. Set this element to `false` if you are using a proxy HTTP server and do not want the URL converted to a non-relative link.

The default behavior is to convert the URL to a non-relative link.

user readable data used in a redirect.

## index-directory-enabled

The <index-directory-enabled> element controls whether or not to automatically generate an HTML directory listing if no suitable index file is found.

The default value is `false` (does not generate a directory). Values are `true` or `false`.

## index-directory-sort-by

The <index-directory-sort-by> element defines the order in which the directory listing generated by weblogic.servlet.FileServlet is sorted. Valid sort-by values are NAME, LAST_MODIFIED, and SIZE. The default sort-by value is NAME.

## servlet-reload-check-secs

The <servlet-reload-check-secs> element defines whether a WebLogic Server will check to see if a servlet has been modified, and if it has been modified, reloads it. The -1 value tells the server never to check the servlets, 0 tells the server to always check the servlets, and the default is to check each 1 second.

A value specified in the console will always take precedence over a manually specified value.

## single-threaded-servlet-pool-size

The <single-threaded-servlet-pool-size> element defines the size of the pool used for SingleThreadMode instance pools. The default value is 5.

## session-monitoring-enabled

The <session-monitoring-enabled> element, if set to true, allows runtime MBeans to be created for sessions. When set to false, the default value, runtime MBeans are not created. A value specified in the console takes precedence over a value set manually.

## save-sessions-enabled

The <save-sessions-enabled> element controls whether session data is cleaned up during redeploy or undeploy. It affects memory and replicated sessions. Setting the value to true means session data is saved. Setting to false means session data will be destroyed when the Web application is redeployed or undeployed. The default is false.

## prefer-web-inf-classes

The <prefer-web-inf-classes> element, if set to true, will cause classes located in the WEB-INF directory of a Web application to be loaded in preference to classes loaded in the application or system classloader. The default value is false. A value specified in the console will take precedence over a value set manually.

## default-mime-type

The <default-mime-type> element default value is null. This element allows the user to specify the default mime type for a content-type for which the extension is not mapped.

## retain-original-url

Set the <retain-original-url> element to true to retain the HTTP in the original URL you are requesting prior to being forwarded to the authentication URL.

Once you login successfully using the authentication URL, you are then taken back to the exact URL that you had originally requested.

# charset-params

The <charset-params> element is used to define code set behavior for non-unicode operations. For example:

>     <charset-params>

>     <input-charset>

>     <resource-path>/*</resource-path>

>     <java-charset-name>UTF-8</java-charset-name>

>     </input-charset>

>     </charset-params>

## input-charset

Use the `<input-charset>` element to define which character set is used to read `GET` and `POST` data. For example:

>     <input-charset>
>         <resource-path>/foo</resource-path>
>         <java-charset-name>SJIS</java-charset-name>
>     </input-charset>

For more information, see Loading Servlets, Context Listeners, and Filters.

The following table describes the elements you can define within a `<input-charset>` element

Element | Required/ Optional | Description
--- | --- | ---
`<resource-path>` | Required | A path which, if included in the URL of a request, signals WebLogic Server to use the Java character set specified by `<java-charset-name>`.
`<java-charset-name>` | Required | Specifies the Java characters set to use.

.

## charset-mapping

Use the `<charset-mapping>` element to map an IANA character set name to a Java character set name. For example:

>     <charset-mapping>
>         <iana-charset-name>Shift-JIS</iana-charset-name>
>         <java-charset-name>SJIS</java-charset-name>
>     </charset-mapping>

For more information, see Mapping IANA Character Sets to Java Character Sets.

The following table describes the elements you can define within a `<charset-mapping>` element

Element | Required/ Optional | Description
--- | --- | ---
`<iana-charset-name>` | Required | Specifies the IANA character set name that is to be mapped to the Java character set specified by the `<java-charset-name>` element.
`<java-charset-name>` | Required | Specifies the Java characters set to use.

.

# virtual-directory-mapping

Use the virtual-directory-mapping element to specify document roots other than the default document root of the Web application for certain kinds of requests, such as image requests. All images for a set of Web applications can be stored in a single location, and need not be copied to the document root of each Web application that uses them. For an incoming request, if a virtual directory has been specified servlet container will search for the requested resource first in the virtual directory and then in the Web application's original document root. This defines the precedence if the same document exists in both places.

Example:

>     <virtual-directory-mapping>

>          <local-path>c:/usr/gifs</local-path>

>          <url-pattern>/images/*</url-pattern>

>          <url-pattern>*.jpg</url-pattern>

>     </virtual-directory-mapping>

>     <virtual-directory-mapping>

>          <local-path>c:/usr/common_jsps.jar</local-path>

>          <url-pattern>*.jsp</url-pattern>

>     </virtual-directory-mapping>

The following table describes the elements you can define within the virtual-directory-mapping element.

Element | Required/ Optional | Description
--- | --- | ---
`<local-path>` | Required | Specifies a physical location on the disk.
<url-pattern> | Required | Contains the URL pattern of the mapping. Must follow the rules specified in Section 11.2 of the Servlet API Specification.

The WebLogic Server implementation of virtual directory mapping requires that you have a directory that matches the url-pattern of the mapping. The image example requires that you create a directory named images at c:/usr/gifs/images. This allows the servlet container to find images for multiple Web applications in the images directory.

# url-match-map

Use this element to specify a class for URL pattern matching. The WebLogic Server default URL match mapping class is weblogic.servlet.utils.URLMatchMap, which is based on J2EE standards. Another implementation included in WebLogic Server is SimpleApacheURLMatchMap, which you can plug in using the url-match-map element.

Rule for SimpleApacheURLMatchMap:

If you map *.jws to JWSServlet then

http://foo.com/bar.jws/baz will be resolved to JWSServlet with pathInfo = baz.

Configure the URLMatchMap to be used in weblogic.xml as in the following example:

>      <url-match-map>

>        weblogic.servlet.utils.SimpleApacheURLMatchMap

>     </url-match-map>

# preprocessor

The preprocessor element contains the declarative data of a preprocessor.

The following table describes the elements you can define within the preprocessor element.

Element | Required/ Optional | Description
--- | --- | ---
`<preprocessor-name>` | Required | Contains the canonical name of the preprocessor.
`<preprocessor-class>` | Required | Contains the fully qualified class name of the preprocessor.

# preprocessor-mapping

The preprocessor-mapping element defines a mapping between a preprocessor and a URL pattern.

The following table describes the elements you can define within the preprocessor-mapping element.

Element | Required/ Optional | Description
--- | --- | ---
`<preprocessor-name>` | Required |
`<url-pattern>` | Required |

# security-permission

The security-permission element specifies a single security permission based on the Security policy file syntax. Refer to the following URL for Sun's implementation of the security permission specification:

http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

Disregard the optional codebase and signedBy clauses.

For example:

>     <security-permission-spec>

>          grant { permission java.net.SocketPermission "*", "resolve" };

>     </security-permission-spec>

where:

permission java.net.SocketPermission is the permission class name.

"*" represents the target name.

resolve indicates the action.

# context-root

The context-root element defines the context root of this stand-alone Web application. If the Web application is part of an EAR, not stand-alone, specify the context root in the EAR's application.xml file. A context-root setting in application.xml takes precedence over context-root setting in weblogic.xml.

Note that this weblogic.xml element only acts on deployments using the two-phase deployment model. See Two-Phase Deployment in Deploying WebLogic Server Applications.

The order of precedence for context root determination for a Web application is as follows:

1. Check application.xml for context root; if found, use as Web application's context root.
2. If context root is not set in application.xml, and the Web application is being deployed as part of an EAR, check whether context root is defined in weblogic.xml. If found, use as Web application's context root. If the Web application is deployed standalone, application.xml does not come into play and the determination for context-root starts at weblogic.xml and defaults to URI if it is not defined there.
3. If context root is not defined in weblogic.xml or application.xmll, then infer the context path from the URI, giving it the name of the value defined in the URI minus the WAR suffix. For instance, a URI MyWebApp.war would be named MyWebApp.

# wl-dispatch-policy

Use the wl-dispatch-policy element to assign the Web application to a configured execute queue by identifying the execute queue name.

# servlet-descriptor

Use the servlet-descriptor element to aggregate the servlet-specific elements.

The following table describes the elements you can define within the servlet-descriptor element.

Element | Required/ Optional | Description
--- | --- | ---
`<servlet-name>` | Required | Specifies the servlet name as defined in the servlet element of the web.xml deployment descriptor file.
`<run-as-principal-name>` | Optional | Contains the name of a principal against the run-as-role-name defined in the web.xml deployment descriptor.
`<init-as-principal-name>` | Optional | Equivalent to run-as-principal-name for the init method for servlets. The identity specified here should be a valid user name in the system. If `init-as-principal-name` is not specified, the container uses the run-as-principal-name element.
`<destroy-as-principal-name>` | Optional | Equivalent to run-as-principal-name for the destroy method for servlets. The identity specified here should be a valid user name in the system. If `destroy-as-principal-name` is not specified, the container uses the run-as-principal-name element.
`<dispatch-policy>` | Optional | This is a deprecated element. Used to assign a given servlet to a configured execute-queue by identifying the execute queue name. This setting overrides the Web application-level dispatch policy defined by wl-dispatch-policy.

# init-as

This is an equivalent of <run-as> for init method for servlets.

For example:

>       <init-as>

>         <servlet-name>FooServlet</servlet-name>

>         <principal-name>joe</principal-name>

>       </init-as>

# destroy-as

This is an equivalent of <run-as> for destroy method for servlets.

For example:

<destroy-as>

<servlet-name>BarServlet</servlet-name>

<principal-name>bob</principal-name>

</destroy-as>