From jboss-remoting-commits at lists.jboss.org Thu May 29 00:08:13 2008 Content-Type: multipart/mixed; boundary="===============6721834829171565202==" MIME-Version: 1.0 From: jboss-remoting-commits at lists.jboss.org To: jboss-remoting-commits at lists.jboss.org Subject: [jboss-remoting-commits] JBoss Remoting SVN: r4264 - remoting2/branches/2.x/docs/guide/en. Date: Thu, 29 May 2008 00:08:13 -0400 Message-ID: --===============6721834829171565202== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: ron.sigal(a)jboss.com Date: 2008-05-29 00:08:13 -0400 (Thu, 29 May 2008) New Revision: 4264 Modified: remoting2/branches/2.x/docs/guide/en/chap11.xml Log: JBREM-840: Added bisocket section and removed multiplex section. Modified: remoting2/branches/2.x/docs/guide/en/chap11.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- remoting2/branches/2.x/docs/guide/en/chap11.xml 2008-05-29 02:53:23 UTC= (rev 4263) +++ remoting2/branches/2.x/docs/guide/en/chap11.xml 2008-05-29 04:08:13 UTC= (rev 4264) @@ -550,6 +550,31 @@ =
+ Bisocket transport + = + The bisocket example shows how to set up push callbacks with the= bisocket transport, using its facility for avoiding the use of a ServerSocket and TCP port on the client. The key section is + = + + HashMap metadata =3D new HashMap(); + metadata.put(Bisocket.IS_CALLBACK_SERVER, "true"); + TestCallbackHandler callbackHandler =3D new TestCallbackHandler(); + client.addListener(callbackHandler, metadata); + + = + which configures the callback Connector a= ppropriately. + = + To run the example, type + = + ant run-bisocket-server + = + in one window, and type + = + ant run-bisocket-client + = + in another window. + = +
+
Streaming = The streaning sample (found in the org.jboss.remoting.samples.st= ream @@ -707,7 +732,7 @@ and expose a remote proxy to it via JBoss Remoting. Dynamic proxies = and reflection are used to make the typed method calls on that target PO= JO. Since JBoss Remoting is used, can select from a number of different - network transports (i.e. rmi, http, socket, multiplex, etc.), includ= ing + network transports (i.e. rmi, http, socket, etc.), including support for SSL. Even clustering features can be included. = How it works @@ -2524,111 +2549,4 @@
= -
- Multiplex invokers - - This section illustrates the construction of multiplex invoker - groups described in the section . The - directory - -
- examples/org/jboss/remoting/samples/multiplex/invoker -
- - contains a server class, - MultiplexInvokerServer, which is suitable for u= se - with any of the client classes described below. It may be run in an ID= E or - from the command line using ant target run-multiplex-server - from the build.xml file found in the examples - directory. The server will stay alive, processing invocation requests = as - they are presented, until it has sent two push callbacks to however ma= ny - listeners are registered, at which time it will shut itself down. - - The sample clients are as follows. Each sample client - <client> may be run in an IDE or by using t= he - ant target run-<client> (e.g., - run-Client2Server1). - - - - Client2Server1: A - MultiplexClientInvoker starts according to - client rule 2, after which a - MultiplexServerInvoker is started according= to - server rule 1. Note that the Client and - Connector are passed matching - clientMultiplexId and - serverMultiplexId parameters, - respectively. - - - - Client2Server2: A - MultiplexClientInvoker starts according to - client rule 2, after which a - MultiplexServerInvoker is started according= to - server rule 2. Note that no clientMultiplexId= is - passed to the Client and no - serverMultiplexId parameter is passed to the - Connector in this example. - - - - Client3Server1: A - MultiplexClientInvoker is created, and, lac= king - binding information, finds itself governed by client rule 3. - Subsequently, a MultiplexServerInvoker is - started according to server rule 1, providing the binding informat= ion - which allows the MultiplexClientInvoker to - start. Note that the Client and - Connector are passed matching - clientMultiplexId and - serverMultiplexId parameters, - respectively. - - - - Server2Client1: A - MultiplexServerInvoker starts according to - server rule 2, after which a - MultiplexClientInvoker is started according= to - client rule 1. Note that the Connector and - Client are passed matching - serverMultiplexId and - clientMultiplexId parameters, - respectively. - - - - Server2Client2: A - MultiplexServerInvoker starts according to - server rule 2, after which a - MultiplexClientInvoker is started according= to - client rule 2. Note that no serverMultiplexId= is - passed to the Connector and no - clientMultiplexId parameter is passed to the - Client in this example. - - - - Server3Client1: A - MultiplexServerInvoker is created, and, lac= king - connect information, finds itself governed by server rule 3. - Subsequently, a MultiplexClientInvoker is - started according to client rule 1, providing the connect informat= ion - which allows the MultiplexServerInvoker to - start. Note that the Connector and - Client are passed matching - serverMultiplexId and - clientMultiplexId parameters, - respectively. - - - - For variety, the examples in which the client invoker starts fir= st - use the configuration Map to pass invoker group - parameters, and the examples in which the server invoker starts first = pass - parameters in the InvokerLocator. -
\ No newline at end of file --===============6721834829171565202==--