[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