<?xml version="1.0" encoding="UTF-8"?>
<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="5.1">

   <xsd:annotation>
      <xsd:documentation> JBoss, Home of Professional Open Source Copyright 2005, JBoss Inc., and
         individual contributors as indicated by the @authors tag. See the copyright.txt 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:documentation>
   </xsd:annotation>

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

	This is the XML Schema for the JBoss 5.1 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://java.sun.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://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd"
           version="5.1">                                     

	       ...

        </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_5_1.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="javaee_5.xsd"/>
   <xsd:include schemaLocation="jboss-common_5_1.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: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="class-loading" type="jboss:class-loadingType" minOccurs="0"/>
         <xsd:element name="security-domain" type="jboss:security-domainType" minOccurs="0"/>
         <xsd:element name="jacc-star-role-allow" type="jboss:jacc-star-role-allowType" minOccurs="0"/>
         <xsd:element name="context-root" type="jboss:context-rootType" minOccurs="0"/>
         <xsd:element name="virtual-host" type="jboss:virtual-hostType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="use-session-cookies" type="jboss:use-session-cookiesType" minOccurs="0"/>
         <xsd:element name="replication-config" type="jboss:replication-configType" minOccurs="0"/>
         <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>
         <xsd:element name="security-role" type="jboss:security-roleType" minOccurs="0" maxOccurs="unbounded"/>
         <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:element name="depends" type="jboss:dependsType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="servlet" type="jboss:servletType" minOccurs="0" maxOccurs="unbounded"/>
         <xsd:element name="max-active-sessions" type="jboss:max-active-sessionsType" minOccurs="0"/>
         <xsd:element name="passivation-config" type="jboss:passivation-configType" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>


   <xsd:complexType name="class-loadingType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            The class-loading element allows one to override the default class
            loading behavior of the web container.
            Examples:
            <class-loading java2ClassLoadingCompliance='false'/>

            <class-loading java2ClassLoadingCompliance='false'>
               <loader-repository loaderRepositoryClass='dot.com.LoaderRepository'>
               ...
               </loader-repository>
            </class-loading>

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

      <xsd:sequence>
         <xsd:element name="loader-repository" type="jboss:loader-repositoryType" minOccurs="0"/>
      </xsd:sequence>

      <xsd:attribute name="java2ClassLoadingCompliance" type="xsd:boolean" use="optional">
         <xsd:annotation>
            <xsd:documentation>
               The java2ClassLoadingCompliance attribute indicates if the normal Java2
               parent first class loading model should be used over the servlet 2.3 web
               container first model.
            </xsd:documentation>
         </xsd:annotation>
      </xsd:attribute>
   </xsd:complexType>

   <xsd:complexType name="jacc-star-role-allowType">
      <xsd:annotation>
         <xsd:documentation>
            (JBAS-1824) 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
            J2EE 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="use-session-cookiesType">
      <xsd:annotation>
         <xsd:documentation>
            <![CDATA[

            The use-session-cookies element controls whether this context uses session cookies or not.

            Example:
               <use-session-cookies>true</use-session-cookies>

            ]]>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:restriction base="javaee:generic-booleanType"/>
      </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-field-batch-mode" type="jboss:replication-field-batch-modeType" 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"
                    3 - "FIELD"

            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.
   
            The third option is useful if the classes stored in the session have been bytecode
            enhanced for use by JBoss PojoCache.  If they have been, the session management layer
            will detect field level changes within objects stored to the session, and will
            replicate those changes.
    
            Examples:
                  <replication-granularity>SESSION</replication-granularity>
               or
                  <replication-granularity>ATTRIBUTE</replication-granularity>
               or
                  <replication-granularity>FIELD</replication-granularity>

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

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

            Determine whether to batch the replication when the granularity level is set to FIELD.
            Default is true.

            If this is set to 'true', that means we will replicate the pojo changes only during the
            http request is finished. To use this, the JBossCacheAop transaction manager class will
            need to be configured as BatchModeTransactionManager such that a user can still have
            UserTransaction inside the http request. However, note that the cache will not particiapte
            in the UserTransaction in this case.

            If you want cache to participate in the UserTransaction, you can configure the transaction
            manager class to JBossTransactionManager and set this option to 'false'. The result is for
            those session attribute changes that are not under transaction will replicate instantaneously,
            while those particiate under transaction will replicate only when the transaction is
            completed.

            Examples:
                  <replication-field-batch-mode>TRUE</replication-field-batch-mode>
               or
                  <replication-field-batch-mode>FALSE</replication-field-batch-mode>

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

   <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: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:schema>