<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.bea.com/ns/weblogic/90" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wls="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
  <xs:include schemaLocation="http://www.bea.com/ns/weblogic/910/weblogic-j2ee.xsd"/>
  <xs:include schemaLocation="http://www.bea.com/ns/weblogic/910/weblogic-application.xsd"/>
  <xs:import namespace="http://java.sun.com/xml/ns/j2ee" schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"/>
  <xs:element name="weblogic-web-app" type="wls:weblogic-web-appType"/>
  <xs:complexType name="weblogic-web-appType">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element name="description" type="wls:descriptionType" minOccurs="0"/>
      <xs:element name="weblogic-version" type="wls:weblogic-versionType" minOccurs="0"/>
      <!--The security-role-assigment declares a mapping between an WebApp security role
      and one or more principals in the WebLogic server. You can also use it to
      mark a given role as an externally-defined role.

      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>

      Example to mark a given role as a externally defined role
         <security-role-assignment>
           <role-name>roleadmin</role-name>
           <externally-defined/>
         </security-role-assignment>-->
      <xs:element name="security-role-assignment" type="wls:security-role-assignmentType" minOccurs="0" maxOccurs="unbounded"/>
      <!--run-as-role-assignment is used to map a given run-as role-name defined
      in web.xml to a valid username in the system. The value can be
      overridden for a given servlet by the run-as-principal-name element
      in the servlet-descriptor. Note that if the run-as-role-assignment is
      absent for a given rolename then the webapp container will choose
      the first principal-name defined in the security-role-assignment,
      if present, else will use the rolename as the run-as-role-assignment.

      Example to specify a given principal ("joe") to be used for run-as
         <run-as-role-assignment>
           <role-name>RunAsRoleName</role-name>
           <run-as-principal-name>joe</run-as-principal-name>
         </run-as-role-assignment>-->
      <xs:element name="run-as-role-assignment" type="wls:run-as-role-assignmentType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:group ref="wls:reference-descriptorGroup"/>
      <xs:element name="message-destination-descriptor" type="wls:message-destination-descriptorType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="session-descriptor" type="wls:session-descriptorType" minOccurs="0"/>
      <xs:element name="jsp-descriptor" type="wls:jsp-descriptorType" minOccurs="0"/>
      <xs:element name="auth-filter" type="wls:auth-filterType" minOccurs="0"/>
      <xs:element name="container-descriptor" type="wls:container-descriptorType" minOccurs="0"/>
      <xs:element name="charset-params" type="wls:charset-paramsType" minOccurs="0"/>
      <xs:element name="virtual-directory-mapping" type="wls:virtual-directory-mappingType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="url-match-map" type="wls:url-match-mapType" minOccurs="0"/>
      <!--security-permission specifies a security permission that
      is associated with a J2EE Sandbox.-->
      <xs:element name="security-permission" type="wls:security-permissionType" minOccurs="0"/>
      <!--The context root of this web application. This is useful for
      standalone web applications. Normally, you would specify the
      context-root in the META-INF/application.xml file of a J2EE
      EAR, however, if this is a standalone web application, you
      can specify the value here.

      The application.xml setting takes precedence over this setting.-->
      <xs:element name="context-root" type="wls:context-rootType" minOccurs="0"/>
      <!--The wl-dispatch-policy can be used to assign the webapp to
      a configured execute queue by identifying the execute queue
      name. This webapp level param can be overridden at the
      individual servlet/jsp level by per-servlet-dispatch-policy.-->
      <xs:element name="wl-dispatch-policy" type="wls:wl-dispatch-policyType" minOccurs="0"/>
      <xs:element name="servlet-descriptor" type="wls:servlet-descriptorType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="work-manager" type="wls:work-managerType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="logging" type="wls:loggingType" minOccurs="0"/>
      <!--library-ref element references a library module, which is intended
      to be used as a webapp library in the current webapp.
        Example:
           <library-ref>
             <library-name>BaseWebApp</library-name>
             <specification-version>2.0</specification-version>
             <implementation-version>8.1beta</implementation-version>
             <exact-match>false</exact-match>
           </library-ref>

           Only the sub-elements: library-name, specification-version (float),
           implementation-version (String) and exact-match (default false) are
           relevant to the webapps. Rest of the sub-elements if present will be
           ignored.-->
      <xs:element name="library-ref" type="wls:library-refType" minOccurs="0" maxOccurs="unbounded"/>
    </xs:choice>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <xs:complexType name="descriptionType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The weblogic-version specifies the version of WebLogic to which
  the weblogic-web-app applies.

  Used in: weblogic-web-app-->
  <xs:complexType name="weblogic-versionType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The jsp-descriptor specifies a list of configuration params
  for the jsp compiler-->
  <xs:complexType name="jsp-descriptorType">
    <xs:sequence>
      <!--Keep generated .java source files-->
      <xs:element name="keepgenerated" type="wls:true-falseType" minOccurs="0"/>
      <!--package prefix for the generated jsp file-->
      <xs:element name="package-prefix" type="xs:string" minOccurs="0"/>
      <!--super-class to be used for the generated jsp class-->
      <xs:element name="super-class" type="xs:string" minOccurs="0"/>
      <!--Interval at which the jsp servlet class is checked for
        staleness against the jsp resource
        default: 1-->
      <xs:element name="page-check-seconds" type="j2ee:xsdIntegerType" minOccurs="0"/>
      <!--compiles all modified jsps at webapp application deployment time or
        server startup time. default: false-->
      <xs:element name="precompile" type="wls:true-falseType" minOccurs="0"/>
      <!--This param indicates whether to continue precompilation even
           when some jsp pages have errors in them.
           default: false-->
      <xs:element name="precompile-continue" type="wls:true-falseType" minOccurs="0"/>
      <!--When set to true, debugging information is printed out to the browser,
        the command prompt, and WebLogic Server log file. default:true-->
      <xs:element name="verbose" type="wls:true-falseType" minOccurs="0"/>
      <!--The name of a directory where WebLogic Server saves the generated Java
        and compiled class files for a JSP.-->
      <xs:element name="working-dir" type="xs:string" minOccurs="0"/>
      <!--When set to false, this parameter ensures that expressions
          with "null" results are printed as " ".
          default:true-->
      <xs:element name="print-nulls" type="wls:true-falseType" minOccurs="0"/>
      <xs:element name="backward-compatible" type="wls:true-falseType" minOccurs="0"/>
      <xs:element name="encoding" type="xs:string" minOccurs="0"/>
      <xs:element name="exact-mapping" type="wls:true-falseType" minOccurs="0"/>
      <xs:element name="default-file-name" type="xs:string" minOccurs="0"/>
      <xs:element name="rtexprvalue-jsp-param-name" type="wls:true-falseType" minOccurs="0"/>
      <xs:element name="debug" type="wls:true-falseType" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="param-nameType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="param-valueType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--This specifies an authentication filter HttpServlet class. This feature has been
  deprecated. Please use "Servlet Authentication Filters" instead.-->
  <xs:complexType name="auth-filterType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The container-descriptor specifies a list of parameters
  that affect the behavior of the web application
  Used in: weblogic-web-app-->
  <xs:complexType name="container-descriptorType">
    <xs:sequence>
      <!--The check-auth-on-forward element, by its presence in a weblogic
      deployment descriptor, indicates that the request dispatcher will
      check authorization when a request is forwarded. By default authorization
      check is not performed on forward.-->
      <xs:element name="check-auth-on-forward" type="j2ee:emptyType" minOccurs="0"/>
      <!--Whether or not apply filters to dispatched requests. It defaults to
      "false". This is a backward compatibility flag. Till 8.1 WebLogic applied
      ServletFilters (if configured for the webapp) on request dispatches
      (includes/forwards) too. Servlet 2.4 has introduced "Dispatcher"
      element to make this behavior explicit. The default value being
      Dispatcher=REQUEST. In order to be spec complaint the default value for
      FilterDispatchedRequestsEnabled is "false" from 9.0 release onwards. Note
      that if you are using old descriptors (meaning web.xml does not have
      version=2.4), then WebLogic automatically uses
      FilterDispatchedRequestsEnabled = true for the webapps, unless
      filter-dispatched-requests-enabled is explicitly set to false in
      weblogic.xml. So the old applications will work fine without any
      change. Also the migration plugin sets this flag to true, during
      the migration of old domains to the 9.0 domain. This value can also
      be set at the domain level for all webapps (WebAppContainerMBean).-->
      <xs:element name="filter-dispatched-requests-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--DEPRECATED: The redirect-content-type element is deprecated since 8.1
      and will be removed in a future version of WebLogic.

      If the redirect-content-type element is set, then
      the servlet container will set that type on the response
      for internal redirects (e.g., for welcome files).-->
      <xs:element name="redirect-content-type" type="wls:redirect-content-typeType" minOccurs="0"/>
      <!--DEPRECATED: The redirect-content element is deprecated since 8.1
      and will be removed in a future version of WebLogic.

      If the redirect-content element is set, then
      the servlet container will use that as the
      value for the user readable data used in a
      redirect.-->
      <xs:element name="redirect-content" type="wls:redirect-contentType" minOccurs="0"/>
      <!--If the redirect-with-absolute-url element is set to false,
      then the servlet container will not convert
      the relative url to the absolute url in the location
      header in a redirect.-->
      <xs:element name="redirect-with-absolute-url" type="wls:true-falseType" minOccurs="0"/>
      <!--Whether or not to automatically generate an HTML
      directory listing if no suitable index file is found.
      Defaults to "false". Value specified via console
      will be given precedence over this setting.-->
      <xs:element name="index-directory-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--This element defines the order of sorting for the directory
      listing generated by weblogic.servlet.FileServlet. Valid values
      are "NAME" (default), "LAST_MODIFIED" and "SIZE".-->
      <xs:element name="index-directory-sort-by" type="wls:index-directory-sort-byType" minOccurs="0"/>
      <!--How often WebLogic checks whether a servlet has been
      modified, and if so reloads it. -1 is never reload, 0 is
      always reload. Default to 1 second. Value specified via
      console will be given precedence over this setting.-->
      <xs:element name="servlet-reload-check-secs" type="j2ee:xsdIntegerType" minOccurs="0"/>
      <!--This parameter is used to do metadata caching for resources cached
      found in the resource path in the webapp scope. This param is to
      tell how often WebLogic checks whether a resource has been
      modified, and if so reloads it. -1 is never reload, 0 is
      always reload. Default to 1 second. Value specified via
      console will be given precedence over this setting.-->
      <xs:element name="resource-reload-check-secs" type="j2ee:xsdIntegerType" minOccurs="0"/>
      <!--Defines the size of the pool used for SingleThreadModel
      instance pools. Defaults to 5. Value specified via
      console will be given precedence over this setting.

      DEPRECATED: since WebLogic 9.0 release, since SingleThreadModel
      has been deprecated since Servlet 2.4-->
      <xs:element name="single-threaded-servlet-pool-size" type="j2ee:xsdNonNegativeIntegerType" minOccurs="0"/>
      <!--If set to true, then runtime mbeans will be created for sessions,
      otherwise, they will not be created. Defaults to false. Value specified
      via console will be given precedence over this setting.

      DEPRECATED: since WebLogic 9.0 release

      This flag is used only for monitoring by the deprecated way using
      weblogic.management.runtime.ServletSessionRuntimeMBean, which
      was expensive and cause memory leaks when the proxies cannot maintain
      stickiness with the primary server for file and jdbc based persistence.
      Therefore the usage of this method of monitoring sessions is not
      recommended. Instead use the new equivalent methods in
      weblogic.management.runtime.WebAppComponentRuntimeMBean:
        getServletSessionsMonitoringIds,
        invalidateServletSession,
        getSessionLastAccessedTime and
        getSessionMaxInactiveInterval.-->
      <xs:element name="session-monitoring-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--This setting controls whether session data is cleaned up during
      redeploy or not. It affects memory and replicated sessions only.
      Setting the value to true means session data is saved. Setting to
      false means session data will be destroyed when the web app is
      redeployed. Sessions will be cleaned up if the webapp is undeployed.
      The default is false. If you are using side-by-side deployments (new
      in diablo) then this setting is not required, since the sessions
      are not affected when a new version of app is deployed.-->
      <xs:element name="save-sessions-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--If true, classes located in the WEB-INF directory of a
      web-app will be loaded in preference to classes loaded
      in the application or system classloader. Defaults to
      false. Value specified via console will be given
      precedence over this setting.-->
      <xs:element name="prefer-web-inf-classes" type="wls:true-falseType" minOccurs="0"/>
      <!--The default mime type to be used for all extensions without
      an explicit Mime map in web.xml-->
      <xs:element name="default-mime-type" type="wls:default-mime-typeType" minOccurs="0"/>
      <!--A true value for client-cert-proxy-enabled overrides the value for
      ClientCertProxyEnabled in webserver/cluster level for each webapp.

      A value of true causes weblogic server to pass identity certificates
      from clients to the backend servers. It also tells the weblogic
      server wether to honor or discard the incoming WL-Proxy-Client-Cert
      header.

      A proxy-server plugin encodes each identify certification in the
      WL-Proxy-Client-Cert header and passes the header to the backend
      WebLogic Server instances. Each WebLogic Server instance takes the
      certificate information from the header, trusting that it came from
      a secure source, and uses that information to authenticate the
      user. For the backend weblogic servers too this parameter has to be
      turned on (either in cluster/server level or webapp level).

      If you specify a true value, use a weblogic.security.net.ConnectionFilter
      to ensure that each WebLogic Server instance accepts connections only
      from the machine on which the proxy-server plugin is running. Specifying
      true without using a connection filter creates a potential security
      vulnerability because the WL-Proxy-Client-Cert header can be spoofed.-->
      <xs:element name="client-cert-proxy-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--relogin-enabled is a backward compatibility parameter. If a user has logged
      in already and tries to access a resource for which he/she doesn't have
      previledges, then spec requires a FORBIDDEN (403) response. In the earlier
      releases (till 8.1) weblogic server used to present the login form again so
      that the end user can relogin as a more previledged user. This value can also
      be set at the domain level for all webapps (WebAppContainerMBean).-->
      <xs:element name="relogin-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--In the security-constraints elements defined in web.xml descriptor
      of web-applications, the auth-constraint element indicates the user roles
      that should be permitted access to this resource collection. Here
      role-name = "*" is a compact syntax for indicating all roles in the
      web application. In the past releases role-name = "*" was treated as
      all users/roles defined in the realm.

      This param is a backward compatibility switch to restore old behavior.
      Default behavior is one required by the spec, meaning all roles
      defained in the web application. The value specified in weblogic.xml
      takes precendence over value defined in the WebAppContainerMBean.-->
      <xs:element name="allow-all-roles" type="wls:true-falseType" minOccurs="0"/>
      <!--To use native I/O while serving static files with weblogic.servlet.FileServlet,
      which is implicitly registered as the default servlet, set native-io-enabled
      to true (default false). This parameter applies only on Windows.-->
      <xs:element name="native-io-enabled" type="wls:true-falseType" minOccurs="0"/>
      <!--The parameter minimum-native-file-size applies only when native-io-enabled is
      true. It sets the minimum file size for using native I/O. If the file being
      served is larger than this value, native I/O is used. If you do not specify
      this parameter, a value of 4096 (4K) is used as default.-->
      <xs:element name="minimum-native-file-size" type="xs:long" minOccurs="0"/>
      <!--When disable-implicit-servlet-mappings flag is turned on, the webapp container
      doesn't create implicit mappings for internal servlets (*.jsp, *.class etc),
      except the default servlet mapping. default = "false". Typical usecase when
      you would want to turn off implicit mappings is when configuring
      HttpClusterServlet or HttpProxyServlet.-->
      <xs:element name="disable-implicit-servlet-mappings" type="wls:true-falseType" minOccurs="0"/>
      <!--Location of temporary directory for the webapp, as returned by 
      "javax.servlet.context.tempDir" context attribute-->
      <xs:element name="temp-dir" type="xs:string" minOccurs="0"/>
      <!--When optimistic-serialization is turned on, WebLogic server does not
      serialize-deserialize context and request attributes upon
      getAttribute(name), when request gets dispatched across servlet contexts.
      This means you will need to make sure that the attributes common to
      webapps are scoped to a common parent classloader; e.g. Application scoped
      or place in system classpath if the two webapps do not belong to the same
      application. When OptimisticSerialization is turned off (default value)
      WebLogic server serialize-deserialize context and request attributes upon
      getAttribute(name) to avoid possibility of ClassCastExceptions.
      optimistic-serialization value can also be specified at domain level
      in WebAppContainerMBean, which applies for all webapps. The value in
      weblogic.xml, if specified, overrides the domain level value.

      defaults to "false".-->
      <xs:element name="optimistic-serialization" type="wls:true-falseType" minOccurs="0"/>
      <!--<p>
      retain-original-url is used in FORM based authentication scenarios. When this property
      is set to true, after a successful authentication, Weblogic Server will redirect back
      to the web resource (page/servlet) retaining the protocol (http/https) used to
      access the protected resource in the original request. If set to false (which is the
      default value), Weblogic Server will redirect back to the protected resource using the
      current protocol.  retain-original-url value can also be specified at domain level in
      WebAppContainerMBean, in which case it will be applied to all the webapps in the domain.
      defaults to "false".
      </p>-->
      <xs:element name="retain-original-url" type="wls:true-falseType" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <!--DEPRECATED: The redirect-content-type element is deprecated since 8.1
  and will be removed in a future version of WebLogic.

  If the redirect-content-type element is set, then
  the servlet container will set that type on the response
  for internal redirects (e.g., for welcome files).-->
  <xs:complexType name="redirect-content-typeType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--DEPRECATED: The redirect-content element is deprecated since 8.1
  and will be removed in a future version of WebLogic.

  If the redirect-content element is set, then
  the servlet container will use that as the
  value for the user readable data used in a
  redirect.-->
  <xs:complexType name="redirect-contentType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--This element defines the order of sorting for the directory
  listing generated by weblogic.servlet.FileServlet. Valid values
  are "NAME" (default), "LAST_MODIFIED" and "SIZE".-->
  <xs:complexType name="index-directory-sort-byType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The default mime type to be used for all extensions without
  an explicit Mime map in web.xml-->
  <xs:complexType name="default-mime-typeType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The charset-params element parameters defines the codeset that
  will be used for non-unicode operations.

  Used in: weblogic-web-app-->
  <xs:complexType name="charset-paramsType">
    <xs:sequence>
      <xs:element name="input-charset" type="wls:input-charsetType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="charset-mapping" type="wls:charset-mappingType" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <!--The input-charset element defines what charset will be
  used to process POST data for a particular resource-->
  <xs:complexType name="input-charsetType">
    <xs:sequence>
      <xs:element name="resource-path" type="wls:resource-pathType"/>
      <xs:element name="java-charset-name" type="wls:java-charset-nameType"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <xs:complexType name="resource-pathType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="java-charset-nameType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The charset-mapping element defines a mapping between
  IANA names and Java names for charsets-->
  <xs:complexType name="charset-mappingType">
    <xs:sequence>
      <xs:element name="iana-charset-name" type="wls:iana-charset-nameType"/>
      <xs:element name="java-charset-name" type="wls:java-charset-nameType"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <xs:complexType name="iana-charset-nameType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--By specifying virtual directory mappings you can change the
  default docroot for certain requests. virtual-directory-mapping
  defines a mapping between url pattern and a new doc root-->
  <xs:complexType name="virtual-directory-mappingType">
    <xs:sequence>
      <xs:element name="local-path" type="wls:local-pathType"/>
      <xs:element name="url-pattern" type="j2ee:url-patternType" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <!--The local-path element specifies a physical location on the disk.-->
  <xs:complexType name="local-pathType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--Using url-match-map you can specify your own
  class for url pattern matching. By default
  weblogic uses weblogic.servlet.utils.ServletMapping
  which is based on J2EE standards. So using
  url-match-map you could overide default behaviour or
  write your own url pattern matcher. The new class
  has to implement weblogic.servlet.utils.URLMapping
  interface.-->
  <xs:complexType name="url-match-mapType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The context root of this web application. This is useful for
  standalone web applications. Normally, you would specify the
  context-root in the META-INF/application.xml file of a J2EE
  EAR, however, if this is a standalone web application, you
  can specify the value here.

  The application.xml setting takes precedence over this setting.-->
  <xs:complexType name="context-rootType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The wl-dispatch-policy can be used to assign the webapp to
  a configured execute queue by identifying the execute queue
  name. This webapp level param can be overridden at the
  individual servlet/jsp level by per-servlet-dispatch-policy.-->
  <xs:complexType name="wl-dispatch-policyType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--The servlet-descriptor aggregates the servlet specific
  elements.-->
  <xs:complexType name="servlet-descriptorType">
    <xs:sequence>
      <!--servlet-name is the servlet-name as defined in web.xml's
      servlet element.-->
      <xs:element name="servlet-name" type="j2ee:servlet-nameType"/>
      <!--The run-as-principal-name element contains the name of a principal
      against the run-as role-name defined in web.xml.-->
      <xs:element name="run-as-principal-name" type="wls:run-as-principal-nameType" minOccurs="0"/>
      <!--init-as-principal-name is equivalent to run-as-principal-name
      for the init method for servlets. The identity specified here
      should be a valid username in the system. If init-as-principal-name
      is not specified the container will use the run-as-principal-name.-->
      <xs:element name="init-as-principal-name" type="wls:init-as-principal-nameType" minOccurs="0"/>
      <!--destroy-as-principal-name is equivalent to run-as-principal-name
      for the destroy method for servlets. The identity specified here
      should be a valid username in the system. If destroy-as-principal-name
      is not specified the container will use the run-as-principal-name.-->
      <xs:element name="destroy-as-principal-name" type="wls:destroy-as-principal-nameType" minOccurs="0"/>
      <!--The dispatch-policy element can be used to assign a given
      servlet to a configured execute-queue by identifying the
      execute queue name. This setting overrides the webapp
      level dispatch policy defined by wl-dispatch-policy.-->
      <xs:element name="dispatch-policy" type="wls:dispatch-policyType" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID"/>
  </xs:complexType>
  <!--init-as-principal-name is equivalent to run-as-principal-name
  for the init method for servlets. The identity specified here
  should be a valid username in the system. If init-as-principal-name
  is not specified the container will use the run-as-principal-name.-->
  <xs:complexType name="init-as-principal-nameType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <!--destroy-as-principal-name is equivalent to run-as-principal-name
  for the destroy method for servlets. The identity specified here
  should be a valid username in the system. If destroy-as-principal-name
  is not specified the container will use the run-as-principal-name.-->
  <xs:complexType name="destroy-as-principal-nameType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="id" type="xs:ID"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:schema>
