[jboss-cvs] JBossAS SVN: r65377 - trunk/server/src/resources/dtd.

[jboss-cvs-commits at lists.jboss.org]

Author: bstansberry at jboss.com
Date: 2007-09-13 14:31:28 -0400 (Thu, 13 Sep 2007)
New Revision: 65377

Modified:
   trunk/server/src/resources/dtd/jboss-web_5_0.dtd
Log:
Use #PCDATA instead of true|false
Add more doc comments

Modified: trunk/server/src/resources/dtd/jboss-web_5_0.dtd
===================================================================
--- trunk/server/src/resources/dtd/jboss-web_5_0.dtd	2007-09-13 18:23:32 UTC (rev 65376)
+++ trunk/server/src/resources/dtd/jboss-web_5_0.dtd	2007-09-13 18:31:28 UTC (rev 65377)
@@ -279,7 +279,7 @@
 -->
 <!ELEMENT depends (#PCDATA)>
 
-<!-- The use-session-cookies element controls wether this context uses session cookies
+<!-- The use-session-cookies element controls whether this context uses session cookies
      or not.
 
 Example:
@@ -314,7 +314,7 @@
    or
    <use-session-passivation>false</use-session-passivation> (default value)
 -->
-<!ELEMENT use-session-passivation (true|false)>
+<!ELEMENT use-session-passivation (#PCDATA)>
 
 <!--
    Clustering only: Determines the minimum time (in seconds) that a session must have been inactive
@@ -374,15 +374,15 @@
    
    In all cases, calling setAttribute marks the session as needing replication.
    
-   The first option is conservative but not optimal (performance-wise): it will replicate the
+   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.
 
-   The second option is conservative but will only replicate if a non-primitive Object has been
-   accessed (i.e. an object not of an immutable JDK type such as Integer, Long, String, etc.). 
-   This is the default value.
+   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.
 
-   The third option assumes that the developer will explicitly call setAttribute on the session
-   if it has to be replicated. This setting prevents unnecessary replication, but requires very
+   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.
 
@@ -410,11 +410,18 @@
    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>
 -->
 <!ELEMENT replication-granularity (#PCDATA)>
 
@@ -422,14 +429,14 @@
    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
+   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
+   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.
@@ -439,11 +446,11 @@
       or
          <replication-field-batch-mode>FALSE</replication-field-batch-mode>
 -->
-<!ELEMENT replication-field-batch-mode (true|false)>
+<!ELEMENT replication-field-batch-mode (#PCDATA)>
 
 <!--
       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 
+      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.,
@@ -456,7 +463,7 @@
       as set in the deployers/jbossweb.deployer service. By default that is set 
       to "false".
 -->
-<!ELEMENT use-jk (true|false)>
+<!ELEMENT use-jk (#PCDATA)>
 
 <!--
       Clustering only: Defines when the sessions are replicated to the other nodes.