docker-jboss-as/jboss-as-7.2.0.Final/docs/schema/jboss-web_7_0.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!--
  ~ JBoss, Home of Professional Open Source.
  ~ Copyright 2012, Red Hat, Inc., and individual contributors
  ~ as indicated by the @author tags. See the copyright.txt file in the
  ~ distribution for a full listing of individual contributors.
  ~
  ~ This is free software; you can redistribute it and/or modify it
  ~ under the terms of the GNU Lesser General Public License as
  ~ published by the Free Software Foundation; either version 2.1 of
  ~ the License, or (at your option) any later version.
  ~
  ~ This software is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of
  ~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  ~ Lesser General Public License for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public
  ~ License along with this software; if not, write to the Free
  ~ Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
  ~ 02110-1301 USA, or see the FSF site: http://www.fsf.org.
  -->

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://www.jboss.com/xml/ns/javaee"
            xmlns:javaee="http://java.sun.com/xml/ns/javaee"
            xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified" 
            attributeFormDefault="unqualified"
            version="7.0">

   <xsd:annotation>
      <xsd:documentation>
         <![CDATA[

	This is the XML Schema for the JBoss AS 7.0 web application deployment descriptor.
	The deployment descriptor must be named "META-INF/jboss-web.xml" in
	the WAR file.  All JBoss Web deployment descriptors must indicate
	the JBoss schema by using the Java EE namespace:

        http://www.jboss.com/xml/ns/javaee

	and by indicating the version of the schema using the version element as shown below:

        <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_7_0.xsd"
           version="7.0">                                     

	       ...

        </jboss-web>

	Instance documents may indicate the published version of
	the schema using the xsi:schemaLocation attribute for the
	Java EE namespace with the following location:

	http://www.jboss.org/j2ee/schema/jboss-web_7_0.xsd

	]]>
      </xsd:documentation>
   </xsd:annotation>

   <xsd:annotation>
      <xsd:documentation> The following conventions apply to all Java EE deployment descriptor
         elements unless indicated otherwise. - In elements that specify a pathname to a file within
         the same JAR file, relative filenames (i.e., those not starting with "/") are considered
         relative to the root of the JAR file's namespace. Absolute filenames (i.e., those starting
         with "/") also specify names in the root of the JAR file's namespace. In general, relative
         names are preferred. The exception is .war files where absolute names are preferred for
         consistency with the Servlet API. </xsd:documentation>
   </xsd:annotation>

   <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_0.xsd"/>
   <xsd:include schemaLocation="jboss-common_6_0.xsd"/>

   <xsd:element name="jboss-web" type="jboss:jboss-webType">
      <xsd:annotation>
         <xsd:documentation>
            This is the root element of jboss-web deployment descriptor.
         </xsd:documentation>
      </xsd:annotation>
   </xsd:element>

  <xsd:simpleType name="jboss-web-versionType">
      <xsd:restriction base="xsd:token">
         <xsd:enumeration value="7.0"/>
      </xsd:restriction>
  </xsd:simpleType>

   <xsd:complexType name="jboss-webType">
      <xsd:annotation>
         <xsd:documentation> The jboss-web element is the root element of jboss-web.xml file. It contains
            all the information used by jboss but not described in the web.xml file. All of it is optional.
         </xsd:documentation>
      </xsd:annotation>

      <xsd:sequence>
         <xsd:element name="context-root" type="jboss:context-rootType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="virtual-host" type="jboss:virtual-hostType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="annotation" type="jboss:annotationType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="listener" type="jboss:container-listenerType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="session-config" type="javaee:session-configType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="valve" type="jboss:valveType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="overlay" type="jboss:overlayType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="security-domain" type="jboss:security-domainType" minOccurs="0"/>
         <xsd:element name="security-role" type="jboss:security-roleType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="jacc-star-role-allow" type="jboss:jacc-star-role-allowType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="disable-cross-context" type="jboss:disable-cross-contextType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="use-jboss-authorization" type="jboss:use-jboss-authorizationType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="disable-audit" type="jboss:disable-auditType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="servlet" type="jboss:servletType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="max-active-sessions" type="javaee:xsdIntegerType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="replication-config" type="jboss:replication-configType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="passivation-config" type="jboss:passivation-configType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="distinct-name" type="jboss:distinct-nameType" minOccurs="0" maxOccurs="1"/>
         <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>
         <xsd:element name="message-destination" type="jboss:message-destinationType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="webservice-description" type="jboss:webservice-descriptionType" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="version" type="jboss:jboss-web-versionType" use="required"/>
   </xsd:complexType>

   <xsd:complexType name="container-listenerType">
      <xsd:annotation>
         <xsd:documentation>
            Defines a web container listener. The module element allows specifying from which
            module in the application server the specified class will be loaded. The listener type
            element defines which events the listener will recieve from the web container.
         </xsd:documentation>
      </xsd:annotation>

      <xsd:sequence>
         <xsd:element name="class-name" type="javaee:string" minOccurs="1" maxOccurs="1"/>
         <xsd:element name="module" type="javaee:string" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="listener-type" type="jboss:container-listener-typeType" minOccurs="1" maxOccurs="1"/>
         <xsd:element name="param" type="javaee:param-valueType" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="container-listener-typeType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Sets the type of the container listener:
                    1 - "LIFECYCLE": webapp lifecycle listener
                    2 - "CONTAINER": webapp container listener
                    3 - "SERVLET_INSTANCE": servlet instance listener
                    4 - "SERVLET_LIFECYCLE": servlet lifecyle listener
                    5 - "SERVLET_CONTAINER": servlet container (Catalina wrapper) listener

            Example:
                  <listener-type>LIFECYCLE</listener-type>

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string">
            <xsd:enumeration value="LIFECYCLE"/>
            <xsd:enumeration value="CONTAINER"/>
            <xsd:enumeration value="SERVLET_INSTANCE"/>
            <xsd:enumeration value="SERVLET_LIFECYCLE"/>
            <xsd:enumeration value="SERVLET_CONTAINER"/>
         </xsd:restriction>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="valveType">
      <xsd:annotation>
         <xsd:documentation>
            Defines a web container valve. The module element allows specifying from which
            module in the application server the specified class will be loaded. A container
            valve is used to intercept the request that will be processed by the servlet. It
            is invoked as part of a chain, before the invocation of the webapp's filter chain.
         </xsd:documentation>
      </xsd:annotation>

      <xsd:sequence>
         <xsd:element name="class-name" type="javaee:string" minOccurs="1" maxOccurs="1"/>
         <xsd:element name="module" type="javaee:string" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="param" type="javaee:param-valueType" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="overlayType">
      <xsd:annotation>
         <xsd:documentation>
            The overlay element specifies additional static files overlays for this
            web application. The content of the element should be a folder in the
            filesystem containing the static files that will overlay the webapp's
            static files, similar to what happens with regular JAR overlays.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="disable-cross-contextType">
      <xsd:annotation>
         <xsd:documentation>
            The disable-cross-context element specifies if cross context
            access should be enabled for this webapp, allowing it to use the
            request dispatcher to access other webapps deployed in the
            application server.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="use-jboss-authorizationType">
      <xsd:annotation>
         <xsd:documentation>
            The use-jboss-authorization element specifies if the JBoss
            authorization layer should be used.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="disable-auditType">
      <xsd:annotation>
         <xsd:documentation>
            The disable-audit element specifies if the security audit logging
            should be disabled.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="distinct-nameType">
      <xsd:annotation>
         <xsd:documentation>
            The distinct-name element specifies the EJB 3 distinct name for this
            web application.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="jacc-star-role-allowType">
      <xsd:annotation>
         <xsd:documentation>
            The jacc-star-role-allow element specifies whether the
            jacc permission generating agent in the web layer needs to generate a
            WebResourcePermission(url,null) permission such that the jacc provider can
            make a decision as to bypass authorization or not.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="context-rootType">
      <xsd:annotation>
         <xsd:documentation>
            The context-root element specifies the context root of a web
            application. This is normally specified at the ear level using the standard
            JEE application.xml descriptor, but it may be given here for standalone wars.
            This should not override the application.xml level specification.
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="virtual-hostType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            The virtual-host element allows one to specify which virtual host the war
            should be deployed to. Example, to specify that a war should be deployed to the
            www.jboss-store.org virtual host add the following virtual-host element:
            <virtual-host>www.jboss-store.org</virtual-host>

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="replication-configType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            HTTP Session clustering configuration (optional tags)

            ]]>
         </xsd:documentation>
      </xsd:annotation>

      <xsd:sequence>
         <xsd:element name="cache-name" type="jboss:cache-nameType" minOccurs="0"/>
         <xsd:element name="replication-trigger" type="jboss:replication-triggerType" minOccurs="0"/>
         <xsd:element name="replication-granularity" type="jboss:replication-granularityType" minOccurs="0"/>
         <xsd:element name="replication-mode" type="jboss:replication-modeType" minOccurs="0"/>
         <xsd:element name="backups" type="jboss:backupsType" minOccurs="0"/>
         <xsd:element name="use-jk" type="jboss:use-jkType" minOccurs="0"/>
         <xsd:element name="max-unreplicated-interval" type="jboss:max-unreplicated-intervalType" minOccurs="0"/>
         <xsd:element name="snapshot-mode" type="jboss:snapshot-modeType" minOccurs="0"/>
         <xsd:element name="snapshot-interval" type="jboss:snapshot-intervalType" minOccurs="0"/>
         <xsd:element name="session-notification-policy" type="jboss:session-notification-policyType" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="cache-nameType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Name of the JBoss Cache or PojoCache configuration that 
            should be used for storing distributable sessions and replicating them around the
            cluster.
        
            Default value if not explicitly set is the overall web container default
            as set in the deployers/jbossweb.deployer service.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="replication-triggerType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Determines when the container should consider that a session
            must be replicated across the cluster.
            Possible values are:
               1 - "ACCESS"
               2 - "SET_AND_GET"
               3 - "SET_AND_NON_PRIMITIVE_GET" (default value)
               4 - "SET"
   
            The rationale for this setting is that after a mutable object stored as a session attribute
            is accessed from the session, in the absence of a setAttribute call the container has no 
            clear way to know if the object (and hence the session state) has been modified.
   
            In all cases, calling setAttribute marks the session as needing replication.
   
            ACCESS - merely accessing the session marks the session as dirty.

            SET_AND_GET is conservative but not optimal (performance-wise): it will always replicate the
            session even if its content has not been modified but simply accessed.

            SET_AND_NON_PRIMITIVE_GET is conservative but will only replicate if a non-primitive Object
            has been accessed (i.e. the object is not of a well-known immutable JDK type such as Integer,
            Long, String, etc.) This is the default value.

            SET assumes that the developer will explicitly call setAttribute on the session
            if it needs to be replicated. This setting prevents unnecessary replication, but requires very
            good coding practices to ensure setAttribute is always called whenever an attribute value
            is modified.

            Examples:
                  <replication-trigger>SET_AND_GET</replication-trigger>
               or
                  <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
               or
                  <replication-trigger>SET</replication-trigger>

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string">
            <xsd:enumeration value="ACCESS"/>
            <xsd:enumeration value="SET_AND_GET"/>
            <xsd:enumeration value="SET_AND_NON_PRIMITIVE_GET"/>
            <xsd:enumeration value="SET"/>
         </xsd:restriction>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="replication-granularityType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Determines the session replication granularity level.
            Possible values are:
                    1 - "SESSION" (default)
                    2 - "ATTRIBUTE"

            The first option indicates that replication is done per session instance, i.e. when
            the session is considered modified, the whole session object will be serialized
            and replicated. This is the preferred policy when the sessions are generally small.

            The second option indicates that replication is performed only for the the dirty
            attributes in the session, plus some session data, like lastAccessTime. For sessions
            carrying large amounts of data, parts of which are infrequently accessed,
            this option can increase replication performance.
   
            A third option, "FIELD" was available in AS 4.x and AS 5.x, but it
            is not supported by AS 6.
    
            Examples:
                  <replication-granularity>SESSION</replication-granularity>
               or
                  <replication-granularity>ATTRIBUTE</replication-granularity>

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string">
            <xsd:enumeration value="SESSION"/>
            <xsd:enumeration value="ATTRIBUTE"/>
         </xsd:restriction>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="replication-modeType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Determines the session replication mode.
            Possible values are:
                1 - "SYNCHRONOUS"
                2 - "ASYNCHRONOUS"

            In SYNCHRONOUS mode, session replication occurs in the same thread that processes a given
            request.  A request will not complete until the associated session is successfully replicated.

            In ASYNCHRONOUS mode, session replication occurs in a separate thread from the one that processes
            a given request.  The request thread only initiates replication, but does not wait for it to complete.

            If not defined, the replication mode defined in the distributed cache configuration will be used.
            In the default distributed session cache configuration, sessions replicate asynchronously.
            
            Examples:
                  <replication-mode>SYNCHRONOUS</replication-mode>
               or
                  <replication-mode>ASYNCHRONOUS</replication-mode>

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string">
            <xsd:enumeration value="SYNCHRONOUS"/>
            <xsd:enumeration value="ASYNCHRONOUS"/>
         </xsd:restriction>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:simpleType name="backupsType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Defines the number of backup nodes on which to replicate
            a given session.
            
            Possible values are:
                > 0 : Session will be replicated to *all* nodes (i.e. total replication)
                  0 : Session will not be replicated (i.e. local mode)
                < 0 : Session will be replicated only to the specified number of nodes (i.e. distribution mode)
            
            Default value, if not explicitly set, is taken from the distributed cache
            configuration.  By default, this is -1, i.e. total replication.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:restriction base="xsd:integer"/>
   </xsd:simpleType>

   <xsd:complexType name="use-jkType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Whether the container should assume mod_jk is used for 
            load balancing for this webapp. If set to 'true', the container will examine 
            the session id associated with every request and replace the JvmRoute portion of
            the session id if it detects a failover. In addition, for each host you will 
            need to set a unique JvmRoute inside the server.xml file, e.g.,
      
            <Engine name="jboss.web" jvmRoute="Node1" defaultHost="localhost">
               ...
            </Engine>
        
            Default value if not explicitly set is the overall web container default
            as set in the deployers/jbossweb.deployer service. By default that is set 
            to "false".

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:simpleType name="max-unreplicated-intervalType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Determines the maximum interval between requests, in 
            seconds, after which a request will trigger replication of the session's 
            timestamp and other metadata regardless of whether the request has otherwise 
            made the session dirty.  Such replication ensures that other nodes in the 
            cluster are aware of the most recent value for the session's timestamp 
            and won't incorrectly expire an unreplicated session upon failover. It also
            results in correct values for HttpSession.getLastAccessedTime() calls 
            following failover.

            The cost of this metadata replication depends on the configured
            replication-granularity. With <code>SESSION</code>, the session's 
            attribute map is replicated along with the metadata, so it can be fairly 
            costly.  With other granularities, the metadata object is replicated 
            separately from the attributes and only contains a String, and a few longs, 
            ints and booleans.
   
            A value of 0 means the metadata will be replicated whenever the session is
            accessed.  A value of -1 means the metadata will be replicated only if some
            other activity during the request (e.g. modifying an attribute) has
            resulted in other replication work involving the session. A positive value
            greater than the HttpSession.getMaxInactiveInterval() value will be treated 
            as a likely misconfiguration and converted to 0; i.e. replicate the 
            metadata on every request.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:restriction base="xsd:integer"/>
   </xsd:simpleType>

   <xsd:complexType name="snapshot-modeType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Defines when the sessions are replicated to the other nodes.
            The typical value, "instant", replicates changes to the other nodes at the end 
            of requests, using the request processing thread to perform the replication. 
            In this case, the "snapshot-interval" property is ignored.
            With "interval" mode, a background process is created that runs every 
            "snapshot-interval" milliseconds, checking for modified sessions and replicating
            them.   
      
            Default value if not explicitly set is the overall web container default
            as set in the deployers/jbossweb.deployer service. By default that is set 
            to "instant".
      
            Note that this property has no effect if replication-granularity
            is set to FIELD. If it is FIELD, "instant" mode will be used.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string">
            <xsd:enumeration value="INSTANT"/>
            <xsd:enumeration value="FIELD"/>
         </xsd:restriction>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:simpleType name="snapshot-intervalType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Defines how often (in milliseconds) the background
            process that replicates modified sessions should be started for this
            web app.  Only meaningful if snapshot-mode is set to "interval".   
      
            Default value if not explicitly set is the overall web container default
            as set in the deployers/jbossweb.deployer service. By default that is set 
            to "1000".

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:restriction base="xsd:integer"/>
   </xsd:simpleType>

   <xsd:complexType name="session-notification-policyType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Fully qualified class name of the implementation of the
            org.jboss.web.tomcat.service.session.notification.ClusteredSessionNotificationPolicy
            interface that should be used to govern whether servlet specification
            notifications should be emitted to any registered HttpSessionListener, 
            HttpSessionAttributeListener and/or HttpSessionBindingListener.
            Event notifications that may make sense in a non-clustered environment
            may or may not make sense in a clustered environment; configuring an
            appropriate ClusteredSessionNotificationPolicy gives the application
            author fine-grained control over what notifications are issued.
      
            Default value if not explicitly set is the 
            org.jboss.web.tomcat.service.session.notification.IgnoreUndeployLegacyClusteredSessionNotificationPolicy.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:fully-qualified-classType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:complexType name="servletType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            The servlet element specifies servlet specific bindings. Currently this
            is only the run-as principal identity.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:sequence>
         <xsd:element name="servlet-name" type="javaee:string"/>
         <xsd:element name="run-as-principal" type="javaee:role-nameType" minOccurs="0">
            <xsd:annotation>
               <xsd:documentation>
                  The run-as-principal element specifies whether a specific run-as identity is
                  to be used. If there is a run-as role defined for a servlet, there can also
                  be a run-as-principal defined here. If you don't define a run-as principal
                  the callee will see ctx.getUserPrincipal() == 'anonymous'
               </xsd:documentation>
            </xsd:annotation>
         </xsd:element>
         <xsd:element name="servlet-security" type="jboss:servlet-securityType" minOccurs="0" maxOccurs="1"/>
      </xsd:sequence>
   </xsd:complexType>

   <xsd:simpleType name="max-active-sessionsType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Determines the max number of active sessions allowed.
            If the number of sessions managed by the the session manager exceeds this value and 
            passivation is enabled, the excess will be passivated based on the configured 
            passivation-min-idle-time.
            If after passivation is completed (or if passivation is disabled), the number of
            active sessions still exceeds this limit, attempts to create new sessions
            will be rejected.
            If set to -1, means no limit

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:restriction base="xsd:integer"/>
   </xsd:simpleType>

   <xsd:complexType name="passivation-configType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: HTTP Session passivation configuration.

            ]]>
         </xsd:documentation>
      </xsd:annotation>

      <xsd:sequence>
         <xsd:element name="use-session-passivation" type="jboss:use-session-passivationType" minOccurs="0"/>
         <xsd:element name="passivation-min-idle-time" type="jboss:passivation-idle-timeType" minOccurs="0">
            <xsd:annotation>
               <xsd:documentation>
                  <![CDATA[

                  Determines the minimum time (in seconds) that a session must have been inactive
                  before the container will consider passivating it in order to reduce the
                  active session count below max-active-sessions.
                  A value of -1 (the default) disables passivating sessions before 
                  passivation-max-idle-time.  Neither a value of -1 nor a high 
                  value are recommended if max-active-sessions is set

                  Example:           
                     <passivation-min-idle-time>30</passivation-min-idle-time> (seconds)

                  ]]>
               </xsd:documentation>
            </xsd:annotation>
         </xsd:element>
         <xsd:element name="passivation-max-idle-time" type="jboss:passivation-idle-timeType" minOccurs="0">
            <xsd:annotation>
               <xsd:documentation>
                  <![CDATA[

                  Determines the maximum time (in seconds) that a session can be inactive before
                  the container should attempt to passivate it to save memory. Passivation of such 
                  sessions will take place regardless of whether the active session count exceeds
                  max-active-sessions.
                  Should be less than the web.xml session-timeout setting.
                  A value of -1 disables passivation based on maximum inactivity.

                  Example:          
                     <passivation-max-idle-time>300</passivation-max-idle-time> (seconds)

                  ]]>
               </xsd:documentation>
            </xsd:annotation>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="use-session-passivationType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Clustering only: Determines whether the web application should use session passivation or not

            Examples:
                  <use-session-passivation>true</use-session-passivation>
               or
                  <use-session-passivation>false</use-session-passivation> (default value)

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </xsd:simpleContent>
   </xsd:complexType>

   <xsd:simpleType name="passivation-idle-timeType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            Determines the time (in seconds) that a session can be inactive before
            the container should attempt to passivate it.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:restriction base="xsd:integer"/>
   </xsd:simpleType>

   <xsd:complexType name="annotationType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            The annotation element specifies annotation specific bindings. This allows
            overriding the @ServletSecurity, @RunAs and @MultipartConfig, which apply
            on a Servlet class rather than a Servlet name. They have the same structure
            and element names as the corresponding annotation.

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:sequence>
         <xsd:element name="class-name" type="javaee:string"/>
         <xsd:element name="servlet-security" type="jboss:servlet-securityType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="run-as" type="jboss:run-asType" minOccurs="0" maxOccurs="1"/>
         <xsd:element name="multipart-config" type="jboss:multipart-configType" minOccurs="0" maxOccurs="1"/>
      </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="run-asType">
    <xsd:sequence>
      <xsd:element name="description" type="javaee:descriptionType" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="role-name" type="javaee:string"/>
    </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="servlet-securityType">
    <xsd:sequence>
      <xsd:element name="empty-role-semantic" type="javaee:string"/>
      <xsd:element name="transport-guarantee" type="javaee:transport-guaranteeType"/>
      <xsd:element name="roles-allowed" type="javaee:role-nameType" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="http-method-constraint" type="jboss:http-method-constraintType" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
   </xsd:complexType>
   
   <xsd:complexType name="http-method-constraintType">
    <xsd:sequence>
      <xsd:element name="method" type="javaee:string" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="empty-role-semantic" type="jboss:empty-role-semanticType"/>
      <xsd:element name="transport-guarantee" type="javaee:transport-guaranteeType"/>
      <xsd:element name="roles-allowed" type="javaee:role-nameType" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
   </xsd:complexType>

   <xsd:complexType name="empty-role-semanticType">
      <xsd:simpleContent>
         <xsd:restriction base="javaee:string">
            <xsd:enumeration value="PERMIT"/>
            <xsd:enumeration value="DENY"/>
         </xsd:restriction>
      </xsd:simpleContent>
   </xsd:complexType>

  <xsd:complexType name="multipart-configType">
    <xsd:sequence>
      <xsd:element name="location" type="javaee:string" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="max-file-size" type="xsd:long" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="max-request-size" type="xsd:long" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="file-size-threshold" type="xsd:integer" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:complexType>

</xsd:schema>