[jboss-remoting-commits] JBoss Remoting SVN: r4700 - remoting2/branches/2.x/docs/guide/en.

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

Author: ron.sigal at jboss.com
Date: 2008-11-18 15:39:41 -0500 (Tue, 18 Nov 2008)
New Revision: 4700

Modified:
   remoting2/branches/2.x/docs/guide/en/chap12.xml
Log:
JBREM-1057: Replacing screwed up chapter.

Modified: remoting2/branches/2.x/docs/guide/en/chap12.xml
===================================================================
--- remoting2/branches/2.x/docs/guide/en/chap12.xml	2008-11-18 20:39:26 UTC (rev 4699)
+++ remoting2/branches/2.x/docs/guide/en/chap12.xml	2008-11-18 20:39:41 UTC (rev 4700)
@@ -1,17 +1,23 @@
   <chapter>
-    <title>Compatibility and versioning</title>
+    <title>Client programming model</title>
 
-    <para>As of JBossRemoting 2.0.0 versioning has been added to guarantee
-    compatibility between different versions. This is accomplished by changing
-    serialization formats for certain classes and by using wire versioning. By
-    wire versioning, mean that the version used by a client and server will be
-    sent on the wire so that the other side will be able to adjust
-    accordingly. This will be automatic for JBossRemoting 2.0.0 and later
-    versions. However, since versioning was not introduced until the 2.0.0
-    release, if need to have a 1.4.x version of remoting communicate to a
-    later version, will need to set a system property on the 2.0.0 version so
-    that knows to use the older wire protocol version. The system property to
-    set is 'jboss.remoting.pre_2_0_compatible' and should be set to true.
-    There are a few minor features that will not be fully compatible between
-    1.4.x release and 2.0.0, which are listed in the release notes.</para>
+    <para>The approach taken for the programming model on the client side is
+    one based on a session based model. This means that it is expected that
+    once a Client is created for a particular target server, it will be used
+    exclusively to make calls on that server. This expectation dictates some
+    of the behavior of the remoting client.</para>
+
+    <para>For example, if create a Client on the client side to make server
+    invocations, including adding callback listeners, will have to use that
+    same instance of Client to remove the callback listeners. This is because
+    the Client creates a unique session id that it passes within the calls to
+    the server. This id is used as part of the key for registering callback
+    listeners on the server. If create a new Client instance and attempt to
+    remove the callback listeners, a new session id will be passed to the
+    server invoker, who will not recognize the callback listener to be
+    removed.</para>
+
+    <para>See test case
+    <code>org.jboss.test.remoting.callback.push.MultipleCallbackServersTestCase</code>
+    .</para>
   </chapter>
\ No newline at end of file