web-2/wildfly/docs/schema/jboss-web_7_3.xsd

855 lines
37 KiB
XML

<?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.3">
<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_3.xsd"
version="7.3">
...
</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_3.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="http://www.jboss.org/schema/jbossas/web-app_3_0.xsd"/>
<xsd:include schemaLocation="http://www.jboss.org/j2ee/schema/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.3"/>
</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:element name="symbolic-linking-enabled" type="jboss:symbolic-linked-allowedType" 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:element name="enable-websockets" type="jboss:enable-websocketsType" minOccurs="0" maxOccurs="1"/>
</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="symbolic-linked-allowedType">
<xsd:annotation>
<xsd:documentation>
The symbolic-linked-allowed element specifies if symlinking is allowed in exploded deployments.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="xsd:boolean"/>
</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:complexType name="enable-websocketsType">
<xsd:annotation>
<xsd:documentation>
The enable-websockets element specifies if websockets
access should be enabled for this webapp. Java version should be at least
1.7 for this to work.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="javaee:generic-booleanType"/>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>