[cvs] expresso commit by lhamel: describe RequestRegistry initialization

[JCorporate Ltd]

Log Message:
-----------
describe RequestRegistry initialization

Modified Files:
--------------
    expresso/expresso-web/expresso/doc:
        ChangeLog.xml

Revision Data
-------------
Index: ChangeLog.xml
===================================================================
RCS file: /home/javacorp/.cvs/expresso/expresso/expresso-web/expresso/doc/ChangeLog.xml,v
retrieving revision 1.269
retrieving revision 1.270
diff -Lexpresso-web/expresso/doc/ChangeLog.xml -Lexpresso-web/expresso/doc/ChangeLog.xml -u -r1.269 -r1.270
--- expresso-web/expresso/doc/ChangeLog.xml
+++ expresso-web/expresso/doc/ChangeLog.xml
@@ -34,11 +34,18 @@
 		unittest, etc reports. Not yet used for building distributions.</explanation>
 				<contributor>Michael Rimov</contributor>
 			</new-feature>
-			<new-feature title="RequestRegistryFilter servlet Filter automatically sets data context and security parameters">
-				<explanation>All calls to setDataContext() will no longer be necessary as the filter propagates the parameter down through the 
-		layers using ThreadLocal variables and the "Registry" pattern as described by Martin Fowler. Security parameters are also propagated 
-		to RowSecuredDBObject, but for the sake of backwards compatibility, they are not propagated to SecuredDBObject. Also, checklogin calls 
-		from the controller can be done away with since it is called at the filter.</explanation>
+			<new-feature title="RequestRegistry automatically sets data context and security parameters">
+				<explanation>All calls to setDataContext() will no longer be necessary in client code.
+        This info is propagated
+		using ThreadLocal variables and the "Registry" pattern as described by Martin Fowler. Security
+        parameters (i.e., requesting UID) are also propagated
+		to RowSecuredDBObject, but for the sake of backwards compatibility, they are not propagated
+        to SecuredDBObject.
+        CheckLogin does this work. However, this functionality is also available in a servlet filter,
+        RequestRegistryFilter.
+        If you choose to use RequestRegistryFilter, you could do away with CheckLogin calls
+		from the controller. We would use RequestRegistryFilter everywhere, but legacy installations have
+        various URL paths, each of which requires filtering.</explanation>
 				<contributor>Michael Rimov</contributor>
 			</new-feature>
 			<new-feature title="Customizable per-instance UserInfo">