[jboss-cvs] JBossRemoting/docs/guide/en ...

Tom Elrod tom.elrod at jboss.com
Mon Jul 24 02:15:59 EDT 2006


  User: telrod  
  Date: 06/07/24 02:15:59

  Modified:    docs/guide/en  master.xml
  Log:
  JBREM-311 - added what thirdparty libs required based on remoting function/transport being used.
  
  Revision  Changes    Path
  1.25      +441 -304  JBossRemoting/docs/guide/en/master.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: master.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossRemoting/docs/guide/en/master.xml,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -b -r1.24 -r1.25
  --- master.xml	6 Jul 2006 07:36:05 -0000	1.24
  +++ master.xml	24 Jul 2006 06:15:59 -0000	1.25
  @@ -430,6 +430,157 @@
     </chapter>
   
     <chapter>
  +    <title>Remoting libraries and thirdparty dependancies</title>
  +
  +    <para>The remoting distribution comes several different version of the
  +    remoting libraries. This is mainly done so the size of the footprint for
  +    can be controlled based on the features of remoting that will be used.
  +    Remoting distribution will include the following remoting binaries (found
  +    in the lib directory of the distribution)</para>
  +
  +    <para><emphasis role="bold">jboss-remoting.jar</emphasis> - this binary
  +    contains all the remoting classes. This is the only remoting jar that is
  +    needed to perform any remoting funtion within JBoss Remoting.</para>
  +
  +    <para>Since some may want to better control size of the binary footprint
  +    needed to use remoting, the remoting classes have been broken out into
  +    multiple remoting binaries based on their function. There are four
  +    categories of these binaries; core, detection, transport, and
  +    other.</para>
  +
  +    <bridgehead>core</bridgehead>
  +
  +    <para><emphasis role="bold">jboss-remoting-core.jar</emphasis> - contains
  +    all the core remoting classes needed for remoting to function. If not
  +    using jboss-remoting.jar, then jboss-remoting.core.jar will be
  +    required.</para>
  +
  +    <bridgehead>detection</bridgehead>
  +
  +    <para><emphasis role="bold">jboss-remoting-detection</emphasis> - contains
  +    all the remoting classes needed to perform automatic discovery of remoting
  +    servers. It includes both the jndi and multicast detector classes as well
  +    as the network registry classes.</para>
  +
  +    <bridgehead>transport</bridgehead>
  +
  +    <para><emphasis role="bold">jboss-remoting-socket.jar</emphasis> -
  +    contains all the classes needed for the socket and sslsocket transports to
  +    function as both a client and a server. </para>
  +
  +    <para><emphasis><emphasis
  +    role="bold">jboss-remoting-socket-client.jar</emphasis></emphasis> -
  +    contains all the classes needed for the socket and sslsocket transports to
  +    function as a client only. This means will not be able to perform any push
  +    callbacks or sending of streams using this jar. </para>
  +
  +    <para><emphasis role="bold">jboss-remoting-http.jar</emphasis> - contains
  +    all the classes needed for the http and https transports to function as a
  +    client and a server. </para>
  +
  +    <para><emphasis role="bold">jboss-remoting-http-client.jar</emphasis> -
  +    contains all the classes needed for the http, https, servlet, and
  +    sslservlet transports to function as a client only. This means will not be
  +    able to perform any push callbacks or sending of streams using this jar.
  +    </para>
  +
  +    <para><emphasis role="bold">jboss-remoting-servlet.jar</emphasis> -
  +    contains all the classes needed for the servlet or sslservlet transports
  +    to function as a server only (also requires servlet-invoker.war be
  +    deployed within web container as well) </para>
  +
  +    <para><emphasis role="bold">jboss-remoting-rmi.jar</emphasis> - contains
  +    all the classes needed for the rmi and sslrmi transports to function as a
  +    client and a server. </para>
  +
  +    <para><emphasis role="bold">jboss-remoting-multiplex.jar</emphasis> -
  +    contains all the classes needed for the multiplex and sslmultiplex
  +    transports to function as a client and a server. Use of this jar also
  +    requires jboss-remoting-socket.jar be on classpath as well.</para>
  +
  +    <bridgehead>other</bridgehead>
  +
  +    <para><emphasis role="bold">jboss-remoting-serialization.jar</emphasis> -
  +    contains just the remoting serialization classes (and serialization
  +    manager implementations for java and jboss).</para>
  +
  +    <para><emphasis role="bold"><emphasis
  +    role="bold">jboss-remoting-samples.jar</emphasis> </emphasis>- all the
  +    remoting samples showing example code for different remotng
  +    functions.</para>
  +
  +    <section>
  +      <title>Thirdparty libraries</title>
  +
  +      <para>This section covers which thirdparty jars are required based on
  +      the feature or transport to be used. Remember, whenever see
  +      jboss-remoting-XXX.jar mentioned, they can all be replaced with just the
  +      jboss-remoting.jar.</para>
  +
  +      <para><emphasis role="bold">All remoting servers:</emphasis>
  +      jboss-remoting-core.jar, jboss-common.jar, jboss-jmx.jar,
  +      log4j.jar</para>
  +
  +      <para><emphasis role="bold">All remoting clients:
  +      </emphasis>jboss-remoting-core.jar, jboss-common.jar, jboss-jmx.jar,
  +      log4j.jar, concurrent.jar</para>
  +
  +      <para>Note: concurrent.jar needed because of org.jboss.util.id.GUID used
  +      to create session id within Client
  +      (http://jira.jboss.com/jira/browse/JBREM-549)</para>
  +
  +      <para>Remoting requires the use of JMX classes. It does not require the
  +      JBoss implementation (jboss-jmx.jar) of JMX in order to function
  +      correctly, so can replace jboss-jmx.jar with another JMX implementation
  +      library (or exclude it if using jdk 1.5 or higher, which has JMX
  +      implementation built in).</para>
  +
  +      <para><emphasis role="bold">Multicast detection:
  +      </emphasis>jboss-remoting-detection.jar, concurrent.jar,
  +      dom4j.jar</para>
  +
  +      <para><emphasis role="bold">JNDI detection:</emphasis>
  +      jboss-remoting-detection.jar, concurrent.jar, dom4j.jar, jnpserver.jar
  +      (for jndi api classes)</para>
  +
  +      <para>The dom4j.jar for use of detection is required because using
  +      jboss-jmx.jar.</para>
  +
  +      <para><emphasis role="bold">Socket server:</emphasis>
  +      jboss-remoting-socket.jar</para>
  +
  +      <para><emphasis role="bold">Socket client:</emphasis>
  +      jboss-remoting-socket-client.jar</para>
  +
  +      <para><emphasis role="bold">HTTP server:</emphasis>
  +      jboss-remoting-http.jar, tomcat-coyote.jar, tomcat-util.jar,
  +      commons-logging-api.jar, tomcat-http.jar</para>
  +
  +      <para>Note: need tomcat-apr.jar and tcnative-1.dll/tcnative-1.so on
  +      system path if want to use APR based tomcat connector</para>
  +
  +      <para><emphasis role="bold">HTTP client:</emphasis>
  +      jboss-remoting-http-client.jar</para>
  +
  +      <para><emphasis role="bold">Servlet server:</emphasis>
  +      servlet-invoker.war (deployed in web container),
  +      jboss-remoting-servlet.jar</para>
  +
  +      <para><emphasis role="bold">Servlet client:</emphasis>
  +      jboss-remoting-http-client.jar</para>
  +
  +      <para><emphasis role="bold">RMI server and client:</emphasis>
  +      jboss-remoting-rmi.jar</para>
  +
  +      <para><emphasis role="bold">Multiplex server and client:</emphasis>
  +      jboss-remoting-socket.jar, jboss-remoting-multiplex.jar</para>
  +
  +      <para><emphasis role="bold">JBoss serialization:</emphasis>
  +      jboss-serialization.jar, trove.jar</para>
  +    </section>
  +  </chapter>
  +
  +  <chapter>
       <title>Configuration</title>
   
       <para>This covers the configuration for JBoss Remoting discovery,
  @@ -1009,26 +1160,24 @@
           <section>
               <title>Socket factories and server socket factories</title>
               
  -	         <para>
  -	         All server invokers use server sockets, and it makes sense,
  -	         therefore, to be able to configure server invokers with
  -	         server socket factories.  It is also true, though less obvious.
  -	         that server invokers create sockets (other than by way of
  -	         server sockets).  When a server invoker makes an asynchronous
  -	         callback to a client, it creates a client invoker, which creates a
  -	         socket.  Moreover, some server invokers, e.g., the RMI server invoker,
  -	         have their own idiosyncratic uses for socket factories.  Remoting offers a
  -	         number of ways of configuring socket factories and server socket
  -	         factories, and these apply to all server invokers.
  -	         </para>
  +          <para>All server invokers use server sockets, and it makes sense,
  +          therefore, to be able to configure server invokers with server
  +          socket factories. It is also true, though less obvious. that server
  +          invokers create sockets (other than by way of server sockets). When
  +          a server invoker makes an asynchronous callback to a client, it
  +          creates a client invoker, which creates a socket. Moreover, some
  +          server invokers, e.g., the RMI server invoker, have their own
  +          idiosyncratic uses for socket factories. Remoting offers a number of
  +          ways of configuring socket factories and server socket factories,
  +          and these apply to all server invokers.</para>
   	         
   	         <para>For <classname>ServerSocketFactory</classname>s, there are
   	         eight means of configuration:</para>
   	         
   	         <orderedlist>
   	            <listitem>
  -	               <para>Call <methodname>Connector.setServerSocketFactory()</methodname>.
  -	               </para>
  +              <para>Call
  +              <methodname>Connector.setServerSocketFactory()</methodname>.</para>
   	            </listitem>
   	            
   	            <listitem>
  @@ -1038,162 +1187,140 @@
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	               Put a constructed <classname>ServerSocketFactory</classname> in a
  -	               configuration map, using key
  -	               <constant>Remoting.CUSTOM_SERVER_SOCKET_FACTORY</constant>,
  -	               and pass the map to one of the <classname>Connector</classname>
  -	               constructors.
  -	               </para>
  +              <para>Put a constructed
  +              <classname>ServerSocketFactory</classname> in a configuration
  +              map, using key
  +              <constant>Remoting.CUSTOM_SERVER_SOCKET_FACTORY</constant>, and
  +              pass the map to one of the <classname>Connector</classname>
  +              constructors.</para>
   	            </listitem>
   	                        
   	            <listitem>
  -	               <para>
  -	                  Put the <classname>ObjectName</classname> of a
  -	                  <classname>ServerSocketFactoryMBean</classname> in a configuration map,
  -	                  using key <constant>ServerInvoker.SERVER_SOCKET_FACTORY</constant>,
  -	                  and pass the map to one of the <classname>Connector</classname>
  -	                  constructors.
  -	               </para>
  +              <para>Put the <classname>ObjectName</classname> of a
  +              <classname>ServerSocketFactoryMBean</classname> in a
  +              configuration map, using key
  +              <constant>ServerInvoker.SERVER_SOCKET_FACTORY</constant>, and
  +              pass the map to one of the <classname>Connector</classname>
  +              constructors.</para>
   	            </listitem>
   	                        
   	            <listitem>
  -	               <para>
  -	               Put the class name of a <classname>ServerSocketFactory</classname>
  -	               in a configuration map, using key
  -	               <constant>ServerInvoker.SERVER_SOCKET_FACTORY</constant>,
  -	               and pass the map to one of the <classname>Connector</classname> constructors.
  -	               In this case, an instance of the class will be created using the default
  -	               constructor. </para>
  +              <para>Put the class name of a
  +              <classname>ServerSocketFactory</classname> in a configuration
  +              map, using key
  +              <constant>ServerInvoker.SERVER_SOCKET_FACTORY</constant>, and
  +              pass the map to one of the <classname>Connector</classname>
  +              constructors. In this case, an instance of the class will be
  +              created using the default constructor.</para>
   	            </listitem>
   	                        
   	            <listitem>
  -	               <para>
  -	               Put a set of SSL parameters, using the keys in
  -	               <classname>org.jboss.remoting.security.SSLSocketBuilder</classname>, in a
  -	               configuration map and pass the map to one of the
  -	               <classname>Connector</classname> constructors. These will be used by
  -	               <classname>SSLSocketBuilder</classname> to create a
  -	               <classname>CustomSSLServerSocketFactory</classname>.
  -	               </para>
  +              <para>Put a set of SSL parameters, using the keys in
  +              <classname>org.jboss.remoting.security.SSLSocketBuilder</classname>,
  +              in a configuration map and pass the map to one of the
  +              <classname>Connector</classname> constructors. These will be
  +              used by <classname>SSLSocketBuilder</classname> to create a
  +              <classname>CustomSSLServerSocketFactory</classname>.</para>
   	            </listitem>
   	                        
   	            <listitem>
  -	               <para>
  -	               Configure an appropriate set of SSL system properties
  -	               and use one of the SSL transports (https, sslmultiplex,
  -	               sslrmi, or sslsocket). The properties will be used to
  -	               create some kind of <classname>SSLServerSocketFactory</classname>,
  -	               as determined by the transport.
  -	               </para>
  +              <para>Configure an appropriate set of SSL system properties and
  +              use one of the SSL transports (https, sslmultiplex, sslrmi, or
  +              sslsocket). The properties will be used to create some kind of
  +              <classname>SSLServerSocketFactory</classname>, as determined by
  +              the transport.</para>
   	            </listitem>
   	                        
   	            <listitem>
  -	               <para>
  -	               Use one of the non-SSL transports and do nothing. A default
  -	               <classname>ServerSocketFactory</classname> will be constructed.
  -	               </para>
  +              <para>Use one of the non-SSL transports and do nothing. A
  +              default <classname>ServerSocketFactory</classname> will be
  +              constructed.</para>
   	            </listitem>
   	         </orderedlist>
   	         
  -	         <para>
  -	            These methods are essentially in descending order of precedence.
  -	            Methods 1) and 2) have equal precedence, and the last one to be
  -	            used prior to calling <methodname>Connector.create()</methodname>
  -	            will determine the <classname>ServerSocketFactory</classname> that
  -	            gets used. Otherwise, if methods 3) and 6), for example, are both
  -	            used, the factory passed in method 3) will prevail.</para>
  -	
  -	         <para>
  -	         For <classname>SocketFactory</classname>s, there are also eight means
  -	         of configuration, and they are essentially the same:</para>
  +          <para>These methods are essentially in descending order of
  +          precedence. Methods 1) and 2) have equal precedence, and the last
  +          one to be used prior to calling
  +          <methodname>Connector.create()</methodname> will determine the
  +          <classname>ServerSocketFactory</classname> that gets used.
  +          Otherwise, if methods 3) and 6), for example, are both used, the
  +          factory passed in method 3) will prevail.</para>
  +
  +          <para>For <classname>SocketFactory</classname>s, there are also
  +          eight means of configuration, and they are essentially the
  +          same:</para>
   	         
   	         <orderedlist>
   	            <listitem>
  -	               <para>
  -	                  Call <methodname>Connector.setSocketFactory()</methodname>.
  -	               </para>
  +              <para>Call
  +              <methodname>Connector.setSocketFactory()</methodname>.</para>
   	            </listitem>
   	
   	            <listitem>
  -	               <para>
  -	                  Get the <classname>ServerInvoker</classname> from the
  +              <para>Get the <classname>ServerInvoker</classname> from the
   	                  <classname>Connector</classname> and call
  -	                  <methodname>ServerInvoker.setSocketFactory()</methodname>.
  -	               </para>
  +              <methodname>ServerInvoker.setSocketFactory()</methodname>.</para>
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	                  Put a constructed <classname>SocketFactory</classname> in a
  -	                  configuration map, using key
  +              <para>Put a constructed <classname>SocketFactory</classname> in
  +              a configuration map, using key
   	                  <constant>Remoting.CUSTOM_SOCKET_FACTORY</constant>, and pass
  -	                  the map to one of the <classname>Connector</classname> constructors.
  -	               
  -	               </para>
  +              the map to one of the <classname>Connector</classname>
  +              constructors.</para>
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	                  Put the <classname>ObjectName</classname> of a
  -	                  <classname>ServerSocketFactoryMBean</classname> in a configuration
  -	                  map, using key <constant>ServerInvoker.SERVER_SOCKET_FACTORY</constant>,
  -	                  and pass the map to one of the <classname>Connector</classname>
  +              <para>Put the <classname>ObjectName</classname> of a
  +              <classname>ServerSocketFactoryMBean</classname> in a
  +              configuration map, using key
  +              <constant>ServerInvoker.SERVER_SOCKET_FACTORY</constant>, and
  +              pass the map to one of the <classname>Connector</classname>
   	                  constructors. If the MBean has type
   	                  <classname>SSLServerSocketFactoryServiceMBean</classname>, its
  -	                  configuration information will be gathered and used to construct a
  -	                  <classname>CustomSSLSocketFactory</classname>.
  -	                  <emphasis role="bold">Note.</emphasis>  This method is guaranteed to
  -	                  work only for callback client invokers.  For other, transport
  -	                  specific, socket factory uses, the transport may or may not
  -	                  use this information.
  -	               </para>
  +              configuration information will be gathered and used to construct
  +              a <classname>CustomSSLSocketFactory</classname>. <emphasis
  +              role="bold">Note.</emphasis> This method is guaranteed to work
  +              only for callback client invokers. For other, transport
  +              specific, socket factory uses, the transport may or may not use
  +              this information.</para>
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	                  Put the class name of a <classname>SocketFactory</classname>
  -	                  in a configuration map, using key
  -	                  <constant>Remoting.SOCKET_FACTORY_NAME</constant>, and pass the map
  -	                  to one of the <classname>Connector</classname> constructors. In this
  -	                  case, an instance of the class will be created using the default constructor.
  -	               
  -	               </para>
  +              <para>Put the class name of a
  +              <classname>SocketFactory</classname> in a configuration map,
  +              using key <constant>Remoting.SOCKET_FACTORY_NAME</constant>, and
  +              pass the map to one of the <classname>Connector</classname>
  +              constructors. In this case, an instance of the class will be
  +              created using the default constructor.</para>
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	                  Put a set of SSL parameters, using the keys in
  +              <para>Put a set of SSL parameters, using the keys in
   	                  <classname>org.jboss.remoting.security.SSLSocketBuilder</classname>,
   	                  in a configuration map and pass the map to one of the
  -	                  <classname>Connector</classname> constructors. These will be used by
  -	                  <classname>SSLSocketBuilder</classname> to create a
  -	                  <classname>CustomSSLSocketFactory</classname>.
  -	               
  -	               </para>
  +              <classname>Connector</classname> constructors. These will be
  +              used by <classname>SSLSocketBuilder</classname> to create a
  +              <classname>CustomSSLSocketFactory</classname>.</para>
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	                  Configure an appropriate set of SSL system properties and use one of
  -	                  the SSL transports (https, sslmultiplex, sslrmi, or sslsocket). The
  -	                  properties will be used to create some kind of
  +              <para>Configure an appropriate set of SSL system properties and
  +              use one of the SSL transports (https, sslmultiplex, sslrmi, or
  +              sslsocket). The properties will be used to create some kind of
   	                  <classname>SSLSocketFactory</classname>, as determined by the
  -	                  transport.
  -	               </para>
  +              transport.</para>
   	            </listitem>
   	            
   	            <listitem>
  -	               <para>
  -	                  Use one of the non-SSL transports and do nothing. Ordinary
  -	                  <classname>Socket</classname>s will be used.
  -	               </para>
  +              <para>Use one of the non-SSL transports and do nothing. Ordinary
  +              <classname>Socket</classname>s will be used.</para>
   	            </listitem>
   	        </orderedlist>
   	          
  -	        <para>Again, these are essentially in descending order of precedence.</para>
  +          <para>Again, these are essentially in descending order of
  +          precedence.</para>
   	      </section>
  -        
         </section>
   
         <section>
  @@ -1365,34 +1492,34 @@
           <para>This is essentially identical to the RMI invoker, except that it
           creates SSL socket and server socket factories by default.</para>
           
  -        <para> 
  -        <emphasis role="bold">Note.</emphasis>  Both the RMI and SSL RMI server
  -        invokers create a socket factory and pass it to a client invoker along
  -        with the RMI stub. Therefore, the socket factory must be serializable.
  -        If the SSL RMI server invoker is allowed to create an 
  -        <classname>SSLSocketFactory</classname> from SSL parameters, it will take
  -        care to create a serializable socket factory.  However, if a socket factory
  -        is passed in to the server invoker by one of the methods discussed earlier,
  -        then the user is responsible for supplying a serializable socket
  -        factory.</para>
  -        
  -        <para>The rules discussed above for configuring socket and server socket 
  -        factories apply to the SSL RMI transport, but there is a twist, since the
  -        server invoker creates the (client) socket factory and packages it with
  -        its own stub.  The server invoker creates a copy of
  +        <para><emphasis role="bold">Note.</emphasis> Both the RMI and SSL RMI
  +        server invokers create a socket factory and pass it to a client
  +        invoker along with the RMI stub. Therefore, the socket factory must be
  +        serializable. If the SSL RMI server invoker is allowed to create an
  +        <classname>SSLSocketFactory</classname> from SSL parameters, it will
  +        take care to create a serializable socket factory. However, if a
  +        socket factory is passed in to the server invoker by one of the
  +        methods discussed earlier, then the user is responsible for supplying
  +        a serializable socket factory.</para>
  +
  +        <para>The rules discussed above for configuring socket and server
  +        socket factories apply to the SSL RMI transport, but there is a twist,
  +        since the server invoker creates the (client) socket factory and
  +        packages it with its own stub. The server invoker creates a copy of
           <classname>org.jboss.remoting.transport.rmi.ssl.SerializableSSLClientSocketFactory</classname>,
  -        which is essentially just a holder for the configuration map passed to the
  -        server invoker, with any parameters removed which concern trust store and
  -        key store configuration.  On the client side, when a client SSL RMI invoker
  -        is created, it stores its own configuration map in a static variable which
  -        the transferred <classname>SerializableSSLClientSocketFactory</classname>
  -        can retrieve and merge with the configuration information it brought with
  -        it from the server.  In particular, if a socket factory is explicitly
  -        passed to the client invoker, then 
  +        which is essentially just a holder for the configuration map passed to
  +        the server invoker, with any parameters removed which concern trust
  +        store and key store configuration. On the client side, when a client
  +        SSL RMI invoker is created, it stores its own configuration map in a
  +        static variable which the transferred
  +        <classname>SerializableSSLClientSocketFactory</classname> can retrieve
  +        and merge with the configuration information it brought with it from
  +        the server. In particular, if a socket factory is explicitly passed to
  +        the client invoker, then
           <classname>SerializableSSLClientSocketFactory</classname> will use it.
           If not, then <classname>SerializableSSLClientSocketFactory</classname>
  -        will use any key store and trust store information passed to the client
  -        to create and configure a socket factory.</para>
  +        will use any key store and trust store information passed to the
  +        client to create and configure a socket factory.</para>
         </section>
         
         <section>
  @@ -2522,34 +2649,45 @@
             <title>Configuration properties</title>
   
             <para>There are four categories of configuration properties
  -          supported by the multiplex invoker, the last three of which are specific
  -          to the multiplex invoker.  Properties in categories 2 and 3 may be
  -          configured by appending them to the server's locator URI.  Properties
  -          in categories 2, 3, and 4 may be configured by putting their values
  -          in a configuration <classname>HashMap</classname> and passing the map
  -          to a <classname>MultiplexServerInvoker</classname> and/or 
  -          <classname>MultiplexClientInvoker</classname> constructor, according
  -          to the category. Constants for the property names in categories
  -          2, 3, and 4 are found in
  +          supported by the multiplex invoker, the last three of which are
  +          specific to the multiplex invoker. Properties in categories 2 and 3
  +          may be configured by appending them to the server's locator URI.
  +          Properties in categories 2, 3, and 4 may be configured by putting
  +          their values in a configuration <classname>HashMap</classname> and
  +          passing the map to a <classname>MultiplexServerInvoker</classname>
  +          and/or <classname>MultiplexClientInvoker</classname> constructor,
  +          according to the category. Constants for the property names in
  +          categories 2, 3, and 4 are found in
             <classname>org.jboss.remoting.transport.multiplex.Multiplex</classname>.
             Note that some of them are also found in the older
             <classname>org.jboss.remoting.transport.multiplex.MultiplexInvokerConstants</classname>,
  -          but the use of that class is now deprecated.
  -          </para>
  +          but the use of that class is now deprecated.</para>
   
             <orderedlist numeration="arabic">
  -            <listitem>The following properties are managed by ancestor classes
  -              of <classname>MultiplexServerInvoker</classname>.  See the discussion
  -              under <classname>SocketServerInvoker</classname> for more information.
  +            <listitem>
  +              The following properties are managed by ancestor classes of 
  +
  +              <classname>MultiplexServerInvoker</classname>
  +
  +              . See the discussion under 
  +
  +              <classname>SocketServerInvoker</classname>
  +
  +               for more information. 
  +
                 <para><emphasis role="bold">socketTimeout</emphasis> - The
                 socket timeout value passed to the
                 <methodname>Socket.setSoTimeout()</methodname> method and the
                 <methodname>ServerSocket.setSoTimeout()</methodname> method. The
                 default is 60000 (or 1 minute).</para>
   
  +               
  +
                 <para><emphasis role="bold">numAcceptThreads</emphasis> - The
                 number of threads that exist for accepting client connections.
                 The default is 1.</para>
  +
  +               
               </listitem>
   
               <listitem>
  @@ -2572,13 +2710,14 @@
                 <classname>MultiplexClientInvoker</classname> with which it
                 should share a multiplex connection.</para>
                 
  -              <para><emphasis role="bold">multiplex.maxAcceptErrors</emphasis> - 
  -              Master and virtual <classname>MultiplexServerInvoker</classname>s
  -              keep a counter of errors experienced by their server socket,
  -              and they terminate when this maximum is exceeded.  Note that
  -              <classname>SSLHandshakeException</classname>s are excluded 
  -              from the count, since they could indicate a client rather
  -              than server error.</para>
  +              <para><emphasis role="bold">multiplex.maxAcceptErrors</emphasis>
  +              - Master and virtual
  +              <classname>MultiplexServerInvoker</classname>s keep a counter of
  +              errors experienced by their server socket, and they terminate
  +              when this maximum is exceeded. Note that
  +              <classname>SSLHandshakeException</classname>s are excluded from
  +              the count, since they could indicate a client rather than server
  +              error.</para>
               </listitem>
   
               <listitem>
  @@ -2622,27 +2761,25 @@
   	    <section>
   	        <title>SSL Multiplex Invoker</title>
   	        
  -	        <para>This transport is essentially identical to the Multiplex transport,
  -	        except that it will create SSL socket factories and server socket factories
  -	        by default.</para>
  +        <para>This transport is essentially identical to the Multiplex
  +        transport, except that it will create SSL socket factories and server
  +        socket factories by default.</para>
   	        
   	        <para>The twist to be found with the multiplex transport is that
   	        virtual <classname>MultiplexServerInvoker</classname>s use a
  -	        <classname>VirtualServerSocket</classname>, which is based on a 
  -	        client rather than a server socket, and consequently they act like
  -	        a client in some ways.  In particular, a virtual
  -	        <classname>MultiplexServerInvoker</classname> will, in some cases, attempt
  -	        to connect to a remote master <classname>MultiplexServerInvoker</classname>,
  -	        for which it will need an actual client socket.  All of the rules
  -	        for configuring socket factories apply to the
  -	        <classname>MultiplexServerInvoker</classname>, which calls the same
  -	        method that client invokers use to get a socket factory.  Moreover,
  -	        if necessary, it will look for a
  +        <classname>VirtualServerSocket</classname>, which is based on a client
  +        rather than a server socket, and consequently they act like a client
  +        in some ways. In particular, a virtual
  +        <classname>MultiplexServerInvoker</classname> will, in some cases,
  +        attempt to connect to a remote master
  +        <classname>MultiplexServerInvoker</classname>, for which it will need
  +        an actual client socket. All of the rules for configuring socket
  +        factories apply to the <classname>MultiplexServerInvoker</classname>,
  +        which calls the same method that client invokers use to get a socket
  +        factory. Moreover, if necessary, it will look for a
   	        <classname>ServerSocketFactoryMBean</classname> to get SSL information
  -	        when configuring a socket factory.
  -	        </para>
  +        when configuring a socket factory.</para>
   	    </section>
  -	    
       </section>
               
       <section>
  @@ -6033,73 +6170,73 @@
   
       <para>Release Notes - JBoss Remoting - Version 1.4.1 final</para>
   
  -    <para>** Feature Request </para>
  +    <para>** Feature Request</para>
   
  -    <para>* [JBREM-310] - Ability to turn connection checking off </para>
  +    <para>* [JBREM-310] - Ability to turn connection checking off</para>
   
       <para>* [JBREM-325] - move IMarshalledValue from jboss-commons to
  -    jboss-remoting.jar </para>
  +    jboss-remoting.jar</para>
   
  -    <para>** Bug </para>
  +    <para>** Bug</para>
   
       <para>* [JBREM-313] - client lease does not work if client and server in
  -    same VM (using local invoker) </para>
  +    same VM (using local invoker)</para>
   
  -    <para>* [JBREM-317] - HTTPClientInvoker conect sends gratuitous POST
  -    </para>
  +    <para>* [JBREM-317] - HTTPClientInvoker conect sends gratuitous
  +    POST</para>
   
  -    <para>* [JBREM-341] - Client ping interval must be lease than lease period
  -    </para>
  +    <para>* [JBREM-341] - Client ping interval must be lease than lease
  +    period</para>
   
  -    <para>* [JBREM-343] - Exceptions on connection closing </para>
  +    <para>* [JBREM-343] - Exceptions on connection closing</para>
   
  -    <para>* [JBREM-345] - problem using client address and port </para>
  +    <para>* [JBREM-345] - problem using client address and port</para>
   
       <para>* [JBREM-346] - fix ConcurrentModificationException in cleanup of
  -    MultiplexServerInvoker </para>
  +    MultiplexServerInvoker</para>
   
  -    <para>* [JBREM-350] - ConcurrentModificationException in InvokerRegistry
  -    </para>
  +    <para>* [JBREM-350] - ConcurrentModificationException in
  +    InvokerRegistry</para>
   
  -    <para>* [JBREM-361] - Race condition in invoking on Client </para>
  +    <para>* [JBREM-361] - Race condition in invoking on Client</para>
   
  -    <para>** Task </para>
  +    <para>** Task</para>
   
  -    <para>* [JBREM-2] - sample-bindings.xml does not have entry for remoting
  -    </para>
  +    <para>* [JBREM-2] - sample-bindings.xml does not have entry for
  +    remoting</para>
   
  -    <para>* [JBREM-220] - clean up remoting wiki </para>
  +    <para>* [JBREM-220] - clean up remoting wiki</para>
   
       <para>* [JBREM-316] - Maintain tomcat originated code under the ASF
  -    license. </para>
  +    license.</para>
   
       <para>* [JBREM-319] - ability to inject socket factory by classname or
  -    instance in all remoting transports </para>
  +    instance in all remoting transports</para>
   
  -    <para>* [JBREM-323] - client lease config changes </para>
  +    <para>* [JBREM-323] - client lease config changes</para>
   
  -    <para>* [JBREM-329] - create global transport config for timeout </para>
  +    <para>* [JBREM-329] - create global transport config for timeout</para>
   
       <para>* [JBREM-330] - create socket server factory based off of
  -    configuration properties </para>
  +    configuration properties</para>
   
       <para>* [JBREM-335] - Client.invoke() should pass configuration map to
  -    InvokerRegistry.createClientInvoker(). </para>
  +    InvokerRegistry.createClientInvoker().</para>
   
       <para>* [JBREM-336] - InvokerRegistry doesn't purge InvokerLocators from
  -    static Set registeredLocators. </para>
  +    static Set registeredLocators.</para>
   
       <para>* [JBREM-337] - PortUtil.findFreePort() should return ports only
  -    between 1024 and 65535. </para>
  +    between 1024 and 65535.</para>
   
  -    <para>* [JBREM-342] - Thread usage for timers and lease functionality
  -    </para>
  +    <para>* [JBREM-342] - Thread usage for timers and lease
  +    functionality</para>
   
       <para>* [JBREM-354] - ServerInvokerCallbackHandler should make its
  -    subsystem accessible. </para>
  +    subsystem accessible.</para>
   
  -    <para>* [JBREM-356] - ServerInvoker should destroy its callback handlers.
  -    </para>
  +    <para>* [JBREM-356] - ServerInvoker should destroy its callback
  +    handlers.</para>
   
       <para>* [JBREM-359] - MultiplexInvokerConfigTestCase should execute
       MultiplexInvokerConfigTestServer instead of
  
  
  



More information about the jboss-cvs-commits mailing list