<?xml version='1.0' encoding='UTF-8' ?>

<!-- The JBoss specific elements used to integrate the servlet 2.3 web.xml
elements into a JBoss deployment. This version applies to the JBoss 3.2.x
releases.

$Id: jboss-web_4_0.dtd,v 1.9.2.3 2005/08/04 14:44:33 dimitris Exp $

  <!DOCTYPE jboss-web PUBLIC
    "-//JBoss//DTD Web Application 2.4//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">

-->

<!-- The jboss-web element is the root element.
-->
<!ELEMENT jboss-web (class-loading?, security-domain?, context-root?,
   virtual-host*, use-session-cookies?, replication-config?, resource-env-ref*,
   resource-ref*, security-role*, ejb-ref*, ejb-local-ref*, 
   message-destination-ref*, message-destination*, 
   service-ref*, webservice-description*, depends*, servlet*)>

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

   <class-loading java2ClassLoadingCompliance='false'>
      <loader-repository loaderRepositoryClass='dot.com.LoaderRepository'>
         ...
      </loader-repository>
   </class-loading>
-->
<!ELEMENT class-loading (loader-repository?)>
<!-- 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.
-->
<!ATTLIST class-loading java2ClassLoadingCompliance CDATA #IMPLIED>

<!-- The loader-repository specifies the name of the UnifiedLoaderRepository
   MBean to use for the ear to provide ear level scoping of classes deployed
   in the ear. It is a unique JMX ObjectName string. It may also specify
   an arbitrary configuration by including a loader-repository-config element.

Examples:
   <class-loading>
   <loader-repository>jboss.test:loader=cts-cmp2v1-sar.ear</loader-repository>
   </class-loading>

   <class-loading java2ClassLoadingCompliance='false'>
   <loader-repository loaderRepositoryClass='dot.com.LoaderRepository'>
      dot.com:loader=unique-archive-name
      <loader-repository-config configParserClass='dot.com.LoaderParser'>
         java2ParentDelegaton=true
      </loader-repository-config>
   </loader-repository>
   </class-loading>
-->
<!ELEMENT loader-repository (#PCDATA | loader-repository-config)*>
<!-- The loaderRepositoryClass attribute gives the classname of the
org.jboss.mx.loading.LoaderRepository implementation.
-->
<!ATTLIST loader-repository loaderRepositoryClass CDATA #IMPLIED>

<!-- The loader-repository-config element specifies any arbitrary configuration
fragment for use in configuring the loader-repository instance. The actual
content of this element is specific to the loaderRepositoryClass and the
code parsing the element.
-->
<!ELEMENT loader-repository-config (#PCDATA)>
<!-- The configParserClass attribute gives the classname of the
org.jboss.mx.loading.LoaderRepositoryFactory.LoaderRepositoryConfigParser
implementation to use to parse the loader-repository-config content.
-->
<!ATTLIST loader-repository-config configParserClass CDATA #IMPLIED>

<!-- 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.
-->
<!ELEMENT context-root (#PCDATA)>

<!-- The security-domain element allows one to specify a module wide
security manager domain. It specifies the JNDI name of the security
manager that implements the org.jboss.security.AuthenticationManager and
org.jboss.security.RealmMapping interfaces for the domain.
-->
<!ELEMENT security-domain (#PCDATA)>

<!-- The flushOnSessionInvalidation attribute is a boolean indicating whether
the associated security domain cache should be flushed when the web session is
invalidated. If true, the security manager service 
flushAuthenticationCache(String, java.security.Principal) is called when the
session is seen to be invalid due to expiration or explicit invalidation.
-->
<!ATTLIST security-domain flushOnSessionInvalidation (true|false) 'false'>

<!-- 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>
-->
<!ELEMENT virtual-host (#PCDATA)>

<!--The resource-env-ref element maps from the servlet ENC relative name
of the resource-env-ref to the deployment environment JNDI name of
the administered object resource.
Example:
    <resource-env-ref>
        <resource-env-ref-name>jms/NewsTopic</resource-env-ref-name>
        <jndi-name>topic/NewsTopic</jndi-name>
    </resource-env-ref>
-->
<!ELEMENT resource-env-ref (resource-env-ref-name , jndi-name)>

<!-- The resource-env-ref-name specifies the name of the web.xml
resource-env-ref-name element which this mapping applies.
-->
<!ELEMENT resource-env-ref-name (#PCDATA)>

<!--The resource-ref element maps from the servlet ENC relative name
of the resource-ref to the deployment environment JNDI name of
the resource manager connection factory.
Example:
    <resource-ref>
        <res-ref-name>jdbc/TheDataSource</res-ref-name>
        <jndi-name>java:/DefaultDS</jndi-name>
    </resource-ref>

    <resource-ref>
        <res-ref-name>jdbc/TheDataSource</res-ref-name>
        <res-url>http://x.y.z</res-url>
    </resource-ref>
-->
<!ELEMENT resource-ref (res-ref-name , (jndi-name | res-url))>

<!-- The res-ref-name specifies the name of the web.xml res-ref-name element
which this mapping applies.
-->
<!ELEMENT res-ref-name (#PCDATA)>

<!--
  The security-role element contains the definition of a security role.
  The definition consists of an the security role name and principal name element(s).

Used in: jboss-web

Example:
		<security-role>
      <role-name>Manager</role-name>
      <principal-name>j2ee</principal-name>
      <principal-name>javajoe</principal-name>
		</security-role>
-->
<!ELEMENT security-role (role-name, principal-name+)>

<!--
  The role-name element is the name of the role.

  Used in: security-role
-->
<!ELEMENT role-name (#PCDATA)>

<!--
  The principal-name element is the name of the principal that is mapped
  to the assembly role-name.

  Used in: security-role
-->
<!ELEMENT principal-name (#PCDATA)>

<!-- The ejb-ref element maps from the servlet ENC relative name
of the ejb reference to the deployment environment JNDI name of
the bean.
Example:
    <ejb-ref>
        <ejb-ref-name>ejb/Bean0</ejb-ref-name>
        <jndi-name>deployed/ejbs/Bean0</jndi-name>
    </ejb-ref>
-->
<!ELEMENT ejb-ref (ejb-ref-name , jndi-name)>

<!-- The ejb-local-ref element maps from the servlet ENC relative name
of the ejb local reference to the deployment environment JNDI name of
the bean.
Example:
    <ejb-local-ref>
        <ejb-ref-name>ejb/Bean0</ejb-ref-name>
        <local-jndi-name>deployed/ejbs/Bean0</local-jndi-name>
    </ejb-local-ref>
-->
<!ELEMENT ejb-local-ref (ejb-ref-name , (local-jndi-name|jndi-name))>

<!-- The ejb-ref-name element gives the ENC relative name used
in the web.xml ejb-ref-name element.

Used in: ejb-ref
-->
<!ELEMENT ejb-ref-name (#PCDATA)>

<!-- The jndi-name element specifies the JNDI name of the deployed
object to which the servlet ENC binding will link to via a JNDI
LinkRef.

Used in: resource-ref, resource-env-ref, ejb-ref, 
         message-destination-ref, message-destination
-->
<!ELEMENT jndi-name (#PCDATA)>

<!--
  The JNDI name under with the local home interface should be bound

  Used in: ejb-local-ref
-->
<!ELEMENT local-jndi-name (#PCDATA)>

<!-- The res-url element value is a URL string for a resource-ref of
res-type = java.net.URL. Using a res-url creates a binding of the URL
instance under the java:comp/env. If you want to link to another binding
of a URL, you can use the jndi-name to do so.

// Binds the URL(http://x.y.z) under java:comp/env/jdbc/XYZHome
<resource-ref>
    <res-ref-name>jdbc/XYZHome</res-ref-name>
    <res-url>http://x.y.z</res-url>
</resource-ref>
// Binds a link to urls/XYZHomePage under java:comp/env/jdbc/XYZHome
<resource-ref>
    <res-ref-name>jdbc/XYZHome</res-ref-name>
    <res-url>urls/XYZHomePage</res-url>
</resource-ref>

   Used in: resource-ref
-->
<!ELEMENT res-url (#PCDATA)>

<!--
  The message-destination-ref element is used to configure the
  jndi-name for a message-destination-ref in ejb-jar.xml

  Used in: jboss-web
-->
<!ELEMENT message-destination-ref (message-destination-ref-name, jndi-name)>

<!--
  The message-destination-ref-name element identifies the
  message-destination-ref. It must match the name in ejb-jar.xml

  Used in: message-destination-ref
-->
<!ELEMENT message-destination-ref-name (#PCDATA)>

<!--
  The message-destination element is used to configure the
  jndi-name for a message-destination in ejb-jar.xml

  Used in: jboss-web
-->
<!ELEMENT message-destination (message-destination-name, jndi-name)>

<!--
  The message-destination-name element identifies the
  message-destination. It must match the name in ejb-jar.xml

  Used in: message-destination
-->
<!ELEMENT message-destination-name (#PCDATA)>

<!-- The depends element gives a JMX ObjectName of a service on which the
container or ejb depends.
-->
<!ELEMENT depends (#PCDATA)>

<!-- The use-session-cookies element controls wether this context uses session cookies
     or not.

Example:
     <use-session-cookies>true</use-session-cookies>
-->
<!ELEMENT use-session-cookies (#PCDATA)>

<!--
   HTTP Session clustering configuration (optional tags)
-->
<!ELEMENT replication-config (replication-trigger?, replication-type?, replication-granularity?)>

<!--
   Clustering only: Determines when the container should consider that a session
                    must be replicated accross the cluster.
                    Possible values are:
                    1 - "SET_AND_GET"
                    2 - "SET_AND_NON_PRIMITIVE_GET" (default value)
                    3 - "SET"

   The first option is conservative but not optimal (performance-wise): it will replicate the
   session even if its content has not been modified but simply accessed. There is no deterministic
   way to know if the content of an attribute is not itself modified. Consequently, by default, no
   hypothesis can be done. It is up to the developer to tell us if we can trust this policy.
   
   The second option is conservative but will only replicate if a non-primitive Object has been
   accessed (Integer, Long, String, etc. which are immutables). It is the default policy.
   
   The third option considers that the developer will explicitely call setAttribute on the session
   if it has to be replicated.

Examples:
         <replication-trigger>SET_AND_GET</replication-trigger>
      or
         <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
      or
         <replication-trigger>SET</replication-trigger>
-->
<!ELEMENT replication-trigger (#PCDATA)>

<!--
   Deprecated since 3.2.6! The mode is configured cluster-wide in tc5-cluster-service.xml
   (through the CacheMode attribute).

   Clustering only: Determines how the container will replicate your sessions.
                    Possible values are:
                    1 - "SYNC" (default)
                    2 - "ASYNC"

   The first option will make sure that the session is actually copied to other nodes of the cluster
   before finishing returning the HTTP request. The session removal and expiration are
   an exception to this rule.
    
   The second option will asynchronously replicate sessions to the other nodes. This is more
   efficient (better scalability and performance) but in case of failover you cannot be sure the
   session has actually arrive on the other node(s).

Examples:
         <replication-type>SYNC</replication-type>
      or
         <replication-type>ASYNC</replication-type>
-->
<!ELEMENT replication-type (#PCDATA)>

<!--
   Clustering only: Determines the session replication granularity level.
                    Possible values are:
                    1 - "SESSION" (default)
                    2 - "ATTRIBUTE"
                    3 - "FIELD" (not yet supported)

   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.
    
Examples:
         <replication-granularity>SESSION</replication-granularity>
      or
         <replication-granularity>ATTRIBUTE</replication-granularity>
-->
<!ELEMENT replication-granularity (#PCDATA)>

<!-- The service-ref element provides jboss specific deployment values to
the web service reference in web.xml.
Example:
    <service-ref>
        <service-ref-name>OrganizationService</service-ref-name>
        <wsdl-override>file:/wsdlRepository/organization-service.wsdl</wsdl-override>
    </service-ref>

    <service-ref>
        <service-ref-name>OrganizationService</service-ref-name>
        <port-component-ref>
          <service-endpoint-interface>com.dot.SEI</service-endpoint-interface>
          <call-property>
            <prop-name>X</prop-name>
            <prop-value>Y</prop-value>
          </call-property>
        </port-component-ref>
    </service-ref>
-->
<!ELEMENT service-ref (service-ref-name, port-component-ref*, wsdl-override?, call-property*)>

<!-- The service-ref-name element gives the ENC relative name used
in the ejb-jar.xml service-ref-name element.

Used in: service-ref
-->
<!ELEMENT service-ref-name (#PCDATA)>

<!-- The port-component-ref element provides additional information about
the standard j2ee service-reference/port-component-ref. Currently this includes
properties that should be associated with the call/stub for the port.

Used in: service-ref
-->
<!ELEMENT port-component-ref (service-endpoint-interface?, call-property*)>

<!-- The wsdl-override element the actual wsdl docuement the web service client
uses to connect to the remote service. It overrides the value of wsdl-file in ejb-jar.xml.

Used in: service-ref
-->
<!ELEMENT wsdl-override (#PCDATA)>

<!-- Fully qualified name of service endpoint interface
-->
<!ELEMENT service-endpoint-interface ( #PCDATA )>

<!-- Arbitrary jaxrpc property values that should be set on a Call object
before it's returned to the web service client. The valid properties can be any
properties supported by the jaxrpc Call implementation.
-->
<!ELEMENT call-property ( prop-name, prop-value )>

<!-- The string value of a property name
-->
<!ELEMENT prop-name (#PCDATA)>

<!-- The string value of a property value
-->
<!ELEMENT prop-value (#PCDATA)>

<!--
Runtime information about a web service.

wsdl-publish-location is optionally used to specify
where the final wsdl and any dependent files should be stored.  This location
resides on the file system from which deployment is initiated.

-->
<!ELEMENT webservice-description ( webservice-description-name, wsdl-publish-location? )>

<!--
Unique name of a webservice within a module
-->
<!ELEMENT webservice-description-name ( #PCDATA )>

<!--
file: URL of a directory to which a web-service-description's wsdl should be
published during deployment.  Any required files will be published to this
directory, preserving their location relative to the module-specific
wsdl directory(META-INF/wsdl or WEB-INF/wsdl).

Example :

  For an ejb.jar whose webservices.xml wsdl-file element contains
    META-INF/wsdl/a/Foo.wsdl

  <wsdl-publish-location>file:/home/user1/publish
  </wsdl-publish-location>

  The final wsdl will be stored in /home/user1/publish/a/Foo.wsdl

-->
<!ELEMENT wsdl-publish-location ( #PCDATA )>

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

   Used in: jboss-web
-->
<!ELEMENT servlet (servlet-name, run-as-principal?)>

<!-- The servlet-name maps from the web.xml servlet/servlet-name to the
jboss-web/servlet/servlet-name.
   Used in: servlet
-->
<!ELEMENT servlet-name ( #PCDATA )>

<!--
  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'

  Used in: servlet
-->
<!ELEMENT run-as-principal ( #PCDATA )>
