[jboss-cvs] JBossAS SVN: r95012 - projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Oct 16 04:18:36 EDT 2009
Author: benlc
Date: 2009-10-16 04:18:36 -0400 (Fri, 16 Oct 2009)
New Revision: 95012
Modified:
projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Book_Info.xml
projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/JBoss_Remoting_User_Guide.xml
projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Revision_History.xml
projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/architecture.xml
projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/components.xml
projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/overview.xml
Log:
'Committing JBoss Remoting Post Tech Review Changes'
Modified: projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Book_Info.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Book_Info.xml 2009-10-16 07:53:44 UTC (rev 95011)
+++ projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Book_Info.xml 2009-10-16 08:18:36 UTC (rev 95012)
@@ -8,9 +8,9 @@
<productname>JBoss Enterprise Application Platform</productname>
<productnumber>5.0</productnumber>
<edition>1.0</edition>
- <pubsnumber>2</pubsnumber>
+ <pubsnumber>3</pubsnumber>
<abstract>
- <para>This book serves as guide to the JBoss Enterpise Application Platform Remoting Project.</para>
+ <para>This book serves as guide to the JBoss Enterprise Application Platform Remoting Project.</para>
</abstract>
<corpauthor>
<inlinemediaobject>
Modified: projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/JBoss_Remoting_User_Guide.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/JBoss_Remoting_User_Guide.xml 2009-10-16 07:53:44 UTC (rev 95011)
+++ projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/JBoss_Remoting_User_Guide.xml 2009-10-16 08:18:36 UTC (rev 95012)
@@ -9,7 +9,8 @@
<xi:include href="overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="components.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-<!-- <xi:include href="remoting_libraries.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
+ <!-- <xi:include href="configuration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
+ <!-- <xi:include href="remoting_libraries.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
<xi:include href="Revision_History.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<!-- <index /> -->
</book>
Modified: projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Revision_History.xml 2009-10-16 07:53:44 UTC (rev 95011)
+++ projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/Revision_History.xml 2009-10-16 08:18:36 UTC (rev 95012)
@@ -7,8 +7,8 @@
<simpara>
<revhistory>
<revision>
- <revnumber>0.1</revnumber>
- <date>Tue Oct 6 2009</date>
+ <revnumber>0.2</revnumber>
+ <date>Fri Oct 16 2009</date>
<author>
<firstname>Ben</firstname>
<surname>Clare</surname>
Modified: projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/architecture.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/architecture.xml 2009-10-16 07:53:44 UTC (rev 95011)
+++ projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/architecture.xml 2009-10-16 08:18:36 UTC (rev 95012)
@@ -159,7 +159,7 @@
</note>
</section>
- <section id="serverdetection"><title>Server Architecture</title>
+ <section id="serverarchitecture"><title>Server Architecture</title>
<para>
<xref linkend="figure:2.3"></xref> depicts the server architecture with the addition of the <emphasis>marshal factory</emphasis>, <emphasis>invoker registry</emphasis> and <emphasis>connector</emphasis>. As per their function on the client, the marshal factory and invoker registry determine the appropriate server invoker and marshaller instances to use. The added connector is responsible for tying the invocation handler to the server invoker and is used as the external point for configuration and control of the remoting server.
@@ -220,7 +220,7 @@
-->
- <section><title>Server Detection</title>
+ <section id="serverdetection"><title>Server Detection</title>
<para>
In order to facilitate automatic detection of servers, it is necessary to add a remoting <emphasis>detector</emphasis> to both the client and the server and add a <emphasis>network registry</emphasis> to the client. The network registry stores the detection information for all of the discovered remoting servers. The additional components required to support automatic detection are depicted in <xref linkend="Figure:2.4"></xref>
Modified: projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/components.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/components.xml 2009-10-16 07:53:44 UTC (rev 95011)
+++ projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/components.xml 2009-10-16 08:18:36 UTC (rev 95012)
@@ -24,87 +24,87 @@
</thead>
<tbody>
<row>
- <entry><package>org.jboss.remoting</package>.<classname>Client</classname></entry>
+ <entry><classname>org.jboss.remoting.Client</classname></entry>
<entry>
- The <classname>Client</classname> class is the main interface for making all invocations, connecting underlying transports to servers, adding and removing listeners (including callback listeners) and setting timeouts. The <classname>Client</classname> constructor requires an <classname>InvokerLocator</classname> object to be passed as a minimum. The <methodname>connect()</methodname> method is used to cause the underlying transport to connect to the remote server for stateful transports such as sockets or when client leasing is turned on. It is recommended, however, to use the <methodname>connect()</methodname> method for all transport types. The <methodname>disconnect()</methodname> method is called to terminate the connection.
+ The <classname>Client</classname> class is the main interface for making all invocations, connecting underlying transports to servers, adding and removing listeners (including callback listeners) and setting timeouts. The <classname>Client</classname> constructor requires an <classname>InvokerLocator</classname> object to be passed as a minimum. The <methodname>connect()</methodname> method is used to cause the underlying transport to connect to the remote server. The <methodname>disconnect()</methodname> method is technically only required for stateful transports such as sockets or when client leasing is turned on. However, it is recommended to use the <methodname>disconnect()</methodname> method for all transport types.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting</package>.<classname>InvokerLocator</classname></entry>
+ <entry><classname>org.jboss.remoting.InvokerLocator</classname></entry>
<entry>
- The <classname>InvokerLocator</classname> class has a single constructor which receives a string in the form of a URI: <programlisting>[transport]://[host]:<port>/path/?<parameter=value>&<parameter=value></programlisting> The URI identifies a particular JBoss Remoting Server JVM and transport protocol. For example, the invoker locator string <uri>socket://192.168.10.1:8080</uri> describes a TCP/IP socket-based transport, listening on port 8080 of the server identified by the IP address 192.168.10.1. Using the string URI or the <classname>InvokerLocator</classname> object JBoss Remoting can make a client connection to the specified remote server.
+ The <classname>InvokerLocator</classname> class has a constructor which receives a string in the form of a URI: <programlisting>[transport]://[host]:<port>/path/?<parameter=value>&<parameter=value></programlisting> The URI identifies a particular JBoss Remoting Server JVM and transport protocol. For example, the invoker locator string <uri>socket://192.168.10.1:8080</uri> describes a TCP/IP socket-based transport, listening on port 8080 of the server identified by the IP address 192.168.10.1. Using the string URI or the <classname>InvokerLocator</classname> object JBoss Remoting can make a client connection to the specified remote server.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.transport</package>.<classname>Connector</classname></entry>
+ <entry><classname>org.jboss.remoting.transport.Connector</classname></entry>
<entry>
The <classname>Connector</classname> class is an MBean that loads a particular server invoker implementation for a given transport subsystem. It also loads one or more server invocation handler implementations which handle subsystem invocations on the remote server JVM. The <classname>Connector</classname> class is the main user interface for configuring and managing a remoting server.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting</package>.<classname>InvocationRequest</classname></entry>
+ <entry><classname>org.jboss.remoting.InvocationRequest</classname></entry>
<entry>
The <classname>InvocationRequest</classname> class is the actual remoting payload of an invocation. This class wraps the caller’s request and provides extra information about the invocation, such as the caller’s session id and the invocation's callback locator, if one exists. An invocation request is passed to the server invocation handler implementation (discussed below).
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting</package>.<interfacename>ServerInvocationHandler</interfacename></entry>
+ <entry><classname>org.jboss.remoting.ServerInvocationHandler</classname></entry>
<entry>
- The <interfacename>ServerInvocationHandler</interfacename> interface must be implemented by the user. It is the interface that the remote server will call as a result of an invocation received from the client. The server invocation handler is responsible for monitoring callback listeners that have been registered by the client.
+ The <classname>ServerInvocationHandler</classname> interface must be implemented by the user. It is the interface that the remote server will call as a result of an invocation received from the client. The server invocation handler is responsible for monitoring callback listeners that have been registered by the client.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.stream</package>.<classname>StreamInvocationHandler</classname></entry>
+ <entry><classname>org.jboss.remoting.stream.StreamInvocationHandler</classname></entry>
<entry>
- The <interfacename>StreamInvocationHandler</interfacename> interface extends the <interfacename>ServerInvocationHandler</interfacename> interface. This interface should be implemented for those handlers which will receive calls from clients that pass an <classname>InputStream</classname> object.
+ The <classname>StreamInvocationHandler</classname> interface extends the <classname>ServerInvocationHandler</classname> interface. This interface should be implemented for those handlers which will receive calls from clients that pass an <classname>InputStream</classname> object.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.callback</package>.<interfacename>InvokerCallbackHandler</interfacename></entry>
+ <entry><classname>org.jboss.remoting.callback.InvokerCallbackHandler</classname></entry>
<entry>
- The <interfacename>InvokerCallbackHandler</interfacename> interface is implemented by any callback listeners. Upon receiving callbacks, the remoting client will call on this interface provided the invoker callback handler has been registered as a callback listener.
+ The <classname>InvokerCallbackHandler</classname> interface is implemented by any callback listeners. Upon receiving callbacks, the remoting client will call on this interface provided the invoker callback handler has been registered as a callback listener.
<!-- /* I think this is correct and not "...the Client has been registered as a callback listener" as the original text is ambiguous*/
-->
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.callback</package>.<classname>Callback</classname></entry>
+ <entry><classname>org.jboss.remoting.callback.Callback</classname></entry>
<entry>
- A <classname>Callback</classname> object is passed to the <interface>InvokerCallbackHandler</interface> interface implementation. It contains the callback payload supplied by the invocation handler, any callback handle object specified when the callback listener was registered, and the locator from which the callback originated.
+ A <classname>Callback</classname> object is passed to the <classname>InvokerCallbackHandler</classname> interface implementation. It contains the callback payload supplied by the invocation handler, any callback handle object specified when the callback listener was registered, and the locator from which the callback originated.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.network</package>.<classname>NetworkRegistry</classname></entry>
+ <entry><classname>org.jboss.remoting.network.NetworkRegistry</classname></entry>
<entry>
The <classname>NetworkRegistry</classname> class is a singleton class that stores new remoting servers as they are detected and removes existing remoting servers that are no longer available on the network. The network registry broadcasts a network notification following a change in the registry.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.network</package>.<classname>NetworkNotification</classname></entry>
+ <entry><classname>org.jboss.remoting.network.NetworkNotification</classname></entry>
<entry>
A <classname>NetworkNotification</classname> object is a Java Management Extensions (JMX) notification containing information about a remoting server change on the network. The notification contains information in regard to the server’s identity and its locators.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.detection</package>.<classname>Detection</classname></entry>
+ <entry><classname>org.jboss.remoting.detection.Detection</classname></entry>
<entry>
A <classname>Detection</classname> object is the detection message broadcast by a detector when a new server is detected, or an existing server is removed from the network. It contains the remoting server's identity as well as the locator and supported subsystems for the server invokers of the remoting server. These details are stored in the <classname>ServerInvokerMetaData</classname> object.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.ident</package>.<classname>Identity</classname></entry>
+ <entry><classname>org.jboss.remoting.ident.Identity</classname></entry>
<entry>
An <classname>Identity</classname> object is one of the main components remoting uses during discovery to identify remoting server instances and is the means by which the uniqueness of remoting servers is guaranteed. If there are two remoting server instances running on the same server, they can be uniquely identified by their <varname>instanceID</varname>, which remains consistent between server reboots, and their <varname>JMXId</varname> which varies with each server reboot. At present, the Ids are maintained in the file system. The ability to identify a server which has encountered problems and has been restarted is important from a monitoring point of view.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.detection.multicast</package>.<classname>MulticastDetector</classname></entry>
+ <entry><classname>org.jboss.remoting.detection.multicast.MulticastDetector</classname></entry>
<entry>
The <classname>MulticastDetector</classname> class implements a detector which transmits its detection message to client detectors using multicast.
</entry>
</row>
<row>
- <entry><package>org.jboss.remoting.detection.jndi</package>.<classname>JNDIDetector</classname></entry>
+ <entry><classname>org.jboss.remoting.detection.jndi.JNDIDetector</classname></entry>
<entry>
The <classname>JNDIDetector</classname> class implements a detector which publishes its detection messages on a JNDI server for later polling by client detectors.
</entry>
@@ -114,7 +114,7 @@
</table>
<section><title>InvokerLocator Points to Note</title>
<para>
- The are some important points to note in regard to the <classname>InvokerLocator</classname>class:
+ The are some important points to note in regard to the <classname>InvokerLocator</classname> class:
</para>
<formalpara><title>InvokerLocator String Modification</title>
<para>
@@ -127,9 +127,14 @@
Supplying an IP address of 0.0.0.0;
</para>
<itemizedlist>
+ <listitem>
+ <para>
+ if the system property <varname>remoting.bind_by_host</varname> is set to <literal> true</literal>, the IP address will be changed to the value of the local host address;
+ </para>
+ </listitem>
<listitem>
<para>
- in this instance, the IP address will be changed to the value of the local host name.
+ otherwise the IP address will be changed to the value of the local host name.
</para>
</listitem>
</itemizedlist>
@@ -147,9 +152,14 @@
</itemizedlist>
</listitem>
</itemizedlist>
+ <note><title>Note</title>
+ <para>
+ Even though the supplied address of 0.0.0.0 will be changed in the InvokerLocator, the server will still bind to the address 0.0.0.0.
+ </para>
+ </note>
<formalpara><title>InvokerLocator Comparisons</title>
<para>
- As of release 2.0.0 of JBoss Remoting, the <classname>InvokerLocator</classname> class will accept a host name for the host portion of the invoker locator string and will not convert the supplied host name to a corresponding IP address. There are two comparison methods which can be used for comparing <classname>InvokerLocator</classname> objects which accept either a host name or an IP address. These methods include:
+ As of release 2.0.0 of JBoss Remoting, the <classname>InvokerLocator</classname> class will accept a host name for the host portion of the invoker locator string. The supplied host name will not be converted to a corresponding IP address unless the system property <varname>remoting.bind_by_host</varname> is set to <literal>true</literal>. There are two comparison methods which can be used for comparing <classname>InvokerLocator</classname> objects which accept either a host name or an IP address. These methods include:
</para>
</formalpara>
<itemizedlist>
@@ -210,13 +220,28 @@
</note>
<formalpara><title>URI Parsing</title>
- <para>As of version 2.4 of JBoss Remoting, the <classname>InvokerLocator</classname> class uses the <classname>java.net.URI</classname> class to parse the locator string passed to its constructor. In the event that the new algorithm causes problems for legacy code, it is possible to configure <classname>InvokerLocator</classname> to use the original parsing code by calling the static method <package>org.jboss.remoting.InvokerLocator</package>.<methodname>setUseLegacyParsing()</methodname>.
+ <para>As of version 2.4 of JBoss Remoting, the <classname>InvokerLocator</classname> class uses the <classname>java.net.URI</classname> class to parse the locator string passed to its constructor. In the event that the new algorithm causes problems for legacy code, it is possible to configure <classname>InvokerLocator</classname> to use the original parsing code by calling the static method <classname>org.jboss.remoting.InvokerLocator</classname>.<methodname>setUseLegacyParsing()</methodname>.
</para>
</formalpara>
</section>
<section><title>Identity Points to Note</title>
+
+ <para>
+ The <methodname>createId()</methodname> method of the <classname>org.jboss.remoting.ident.Identity</classname> class firstly checks whether the <literal>jboss.identity</literal> system property has been set and, if so, returns the corresponding string.
+ </para>
+
+ <para>
+ If the system property has not been set, the <literal>ServerDataDir</literal> attribute of the <literal>jboss.system:type=ServerConfig</literal> MBean will be retrieved and a <classname>File</classname> object will be instantiated using the relevant path. If the directory does not exist, it will be created prior to instantiating the <classname>File</classname> object.
+ </para>
+ <para>
+ In the absence of the <literal>ServerDataDir</literal> attribute, an attempt will be made to retrieve the <literal>jboss.identity.dir</literal> system property and, upon success, a <classname>File</classname> object will be instantiated based on the relevant path. Once again, if the directory does not exist ,it will be created prior to instantiating the <classname>File</classname> object. In the event that the <literal>jboss.identity.dir</literal> system property has not been set, the current directory (".") will be used as the path.
+ </para>
+ <para>
+ Once the <classname>File</classname> object has been instantiated, a check is performed to determine whether the file exists on the system and whether it is readable. If so, the id of the server is read from the file, assigned to the <literal>jboss.identity</literal> system property and returned. If the file does not exist, it is created and the <methodname>createUniqueId()</methodname> method is called. The returned id is then written to the file and assigned to the <literal>jboss.identity</literal> system property.
+ </para>
+ <!--
<para>
- When creating the identity to be persisted, JBoss Remoting will attempt to write to the <filename>'jboss.identity'</filename> file according to the following sequence:
+ When creating the identity to be persisted, the <methodname>createId()</methodname> method will either retrieve an existing id form an existing file or create and write a unique id according to the following sequence:
</para>
<orderedlist>
<listitem>
@@ -226,7 +251,7 @@
</listitem>
<listitem>
<para>
- If the property has been set, JBoss Remoting will use this property to record the details of the JBoss server instance or identity.
+ If the property has been set, the <methodname>createId()</methodname> method will return this value.
</para>
<itemizedlist>
<listitem>
@@ -238,7 +263,7 @@
</listitem>
<listitem>
<para>
- Upon successfully retrieving the <filename>'ServerDataDir'</filename> attribute above, JBoss Remoting will use this directory to write a new instance of the <filename>'jboss.identity'</filename> file.
+ Upon successfully retrieving the <filename>'ServerDataDir'</filename> attribute above, JBoss Remoting will check for the existance of this directory and create it if it is not exist.
</para>
<itemizedlist>
<listitem>
@@ -250,23 +275,29 @@
</listitem>
<listitem>
<para>
- If the <filename>'jboss.identity.dir'</filename> property above has been set, the <filename>'jboss.identity'</filename> file will be written to the <filename>'jboss.identity.dir'</filename> directory.
+ If the <filename>'jboss.identity.dir'</filename> property above has been set, JBoss Remoting will check for the existance of this directory and create it if it is not exist.
</para>
</listitem>
<listitem>
<para>
- Failing the above attempts, the <filename>'jboss.identity'</filename> file will be written to the current directory (".").
+ Failing the above attempts, the current directory (".") will be used.
</para>
</listitem>
+ <listitem>
+ <para>
+ Once the directory has been established, the id will be read form the jboss.identity or, if this file does not exist, a unique identity will be created and written to the newly created file.
+ </para>
+ </listitem>
</orderedlist>
+ -->
<important><title>Important</title>
<para>
- A RuntimeException will be thrown in the event that the 'jboss.identity' file cannot be created or modified. This will result in the detector producing errors during start-up. More details in regard to maintaining the persistence of the identity and the location to which the identity is stored can be found in <package>org.jboss.remoting.ident.Identity</package>.<classname>createId()</classname>.
+ A RuntimeException will be thrown in the event that the 'jboss.identity' file cannot be created or modified. This will result in the detector producing errors during start-up. More details in regard to maintaining the persistence of the identity and the location to which the identity is stored can be found in <classname>.org.jboss.remoting.ident.Identity</classname>.<methodname>createId()</methodname>
</para>
</important>
</section>
</section>
- <section><title>Non-class Implemented Components </title>
+ <section><title>Other Concepts</title>
<para>
There are some components which are not implemented as classes but are important to the JBoss Remoting platform.
@@ -312,7 +343,7 @@
</para>
-->
<para>
- Under normal circumstances, remote server detection is a passive operation causing events to be triggered as a result of the receipt of detection messages by the client detector. In some cases, the ability to synchronously discover the remoting servers that exist upon start-up is required. This can be achieved by calling the <methodname>forceDetection()</methodname> method (defined and implemented in the <classname>AbstractDetector</classname> class) on the detector which will return an array of <classname>NetworkInstances</classname> objects containing the server information.
+ Under normal circumstances, remote server detection is a passive operation causing events to be triggered as a result of the receipt of detection messages by the client detector. In some cases, the ability to synchronously discover the remoting servers that exist upon start-up is required. This can be achieved by calling the <methodname>forceDetection()</methodname> method (defined and implemented in the <classname>AbstractDetector</classname> class) on the detector, which will return an array of <classname>NetworkInstances</classname> objects containing the server information.
</para>
<note><title>Note</title>
<para>
@@ -378,43 +409,43 @@
<!-- <section><title>Loading an Invoker</title> -->
<para>
- The JBoss Remoting transport implementations (<emphasis>invokers</emphasis>) are responsible for handling the transport protocol to be used by JBoss Remoting clients and servers. The JBoss Remoting platform loads client and server invoker implementations within the invoker registry using factories. The factory classes to use in order to load a client and server invoker are <classname>TransportClientFactory</classname> and <classname>TransportServerFactory</classname> respectively. These classes must implement the following interfaces:
+ The JBoss Remoting transport implementations (<emphasis>invokers</emphasis>) are responsible for handling the transport protocol to be used by JBoss Remoting clients and servers. The JBoss Remoting platform loads client and server invoker implementations within the invoker registry using factories. The factory classes to use in order to load a client and server invoker are <classname>TransportClientFactory</classname> and <classname>TransportServerFactory</classname> respectively. These classes must implement the following interfaces, respectively:
</para>
<itemizedlist>
<listitem>
<para>
- <package>org.jboss.remoting.transport</package>.<interface>ClientFactory</interface> and;
+ <classname>org.jboss.remoting.transport.ClientFactory</classname> and,
</para>
</listitem>
<listitem>
<para>
- <package>org.jboss.remoting.transport</package>.<interface>ServerFactory</interface>.
+ <classname>org.jboss.remoting.transport.ServerFactory</classname>.
</para>
</listitem>
</itemizedlist>
<para>
- The classes relating to a particular transport protocol are located under the <package>org.jboss.remoting.transport.[transportname]</package> package. For example the <classname>TransportClientFactory</classname> and <classname>TransportServerFactory</classname> interfaces relating to the socket transport protocol are located under the <package>org.jboss.remoting.transport.socket</package> package.
+ The classes relating to a particular transport protocol are located under the <classname>org.jboss.remoting.transport.[transportname]</classname> package. For example the <classname>TransportClientFactory</classname> and <classname>TransportServerFactory</classname> interfaces relating to the socket transport protocol are located under the <classname>org.jboss.remoting.transport.socket</classname> package.
</para>
<!-- </section> -->
<section><title>Client and Server Factory APIs</title>
<para>
- The <abbrev>API</abbrev> for <package>org.jboss.remoting.transport.socket</package>.<classname>ClientFactory</classname> is:
+ The API for <classname>org.jboss.remoting.transport.ClientFactory</classname> is:
<programlisting>public ClientInvoker createClientInvoker(InvokerLocator locator, Map config) throws IOException;
public boolean supportsSSL();
</programlisting>
</para>
<para>
- The <abbrev>API</abbrev> for <package>org.jboss.remoting.transport.socket</package>.<classname>ServerFactory</classname> is:
+ The API for <classname>org.jboss.remoting.transport.ServerFactory</classname> is:
<programlisting>public ServerInvoker createServerInvoker(InvokerLocator locator, Map config) throws IOException;
public boolean supportsSSL();
</programlisting>
</para>
<para>
- An example of a transport client factory for the socket transport (<package>org.jboss.remoting.transport.socket</package>.<classname>TransportClientFactory</classname>) is:
+ An example of a transport client factory for the socket transport (<classname>org.jboss.remoting.transport.socket.TransportClientFactory</classname>) is:
</para>
<programlisting>public class TransportClientFactory implements ClientFactory
@@ -433,7 +464,7 @@
</programlisting>
<note><title>Note</title>
<para>
- The transport factories are loaded following a request for a particular protocol type which is then passed to the <methodname>createClientInvoker()</methodname> method as part of the (<type>Map</type> <parameter>config</parameter>) parameter.
+ The transport factories are loaded following a request for a particular protocol type.
</para>
</note>
@@ -441,7 +472,7 @@
</para>
<para>
- Any package may be used within the factory provided it is on the CLASSPATH. The client and server factories have been separated so that only the factory requested is loaded along with the corresponding classes needed for that invoker implementation. As a result, a request for a particular client transport invoker will only load the relevant client classes. Those classes that are required for the server are not required to be on the CLASSPATH. This approach allows users the ability to plug in custom transport implementations without the need for their configuration.
+ Any package may be used within the factory provided it is on the classpath. The client and server factories have been separated so that only the factory requested is loaded along with the corresponding classes needed for that invoker implementation. As a result, a request for a particular client transport invoker will only load the relevant client classes. Those classes that are required for the server are not required to be on the classpath.
</para>
</section>
</section>
Modified: projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/overview.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/overview.xml 2009-10-16 07:53:44 UTC (rev 95011)
+++ projects/docs/enterprise/5.0/JBoss_Remoting/JBoss_Remoting_User_Guide/en-US/overview.xml 2009-10-16 08:18:36 UTC (rev 95012)
@@ -409,42 +409,43 @@
-->
<section><title>What's New in Version 2.5?</title>
<para>
- Version 2.5.0 represents the process of upgrading the jars with which JBoss Remoting is tested and shipped. In particular, the jars are now equivalent to the jars found in the JBoss Application Server version 5.0.0.CR2. Changes to jbossweb have necessitated an end to the use of Apache Tomcat. This has resulted in the non-functionality of the "http" transport with the use of jdk 1.4. Other features of remoting 2.5.0.GA should function under jdk 1.4, however, this version of the jdk is no longer supported.
+ Version 2.5.0 represents the process of upgrading the jars with which JBoss Remoting is tested and shipped. In particular, the jars are now equivalent to the jars found in the JBoss Application Server version 5.0.0.CR2. Changes to jbossweb have necessitated an end to the use of Apache Tomcat. This has resulted in the non-functionality of the "http" transport with the use of jdk 1.4. Other features of remoting 2.5.0.GA should function under jdk 1.4; however this version of the jdk is no longer supported.
</para>
<formalpara>
<title>Release 2.5.2</title>
<para>
- Release 2.5.2 consisted of the following:
+ Release 2.5.2 delivered the following:
</para>
</formalpara>
<itemizedlist>
<listitem>
<para>
- Introduction of "connection identity" concept
+ Introduction of "connection identity" concept.
</para>
</listitem>
<listitem>
<para>
- Introduction of write timeout facility;
+ Introduction of write timeout facility.
</para>
- <itemizedlist>
- <listitem>
- <para>improved reliability for callbacks in bisocket transport;</para>
- </listitem>
- <listitem>
- <para>
- improved treatment of invocation retries in socket and bisocket transports;
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
+ </listitem>
<listitem>
<para>
- More flexible configuration (see <package>org.jboss.remoting</package>.<classname>Remoting</classname>.<constant>CONFIG_OVERRIDES_LOCATOR</constant>).
+ Improved reliability for callbacks in bisocket transport.
</para>
</listitem>
<listitem>
<para>
+ Improved treatment of invocation retries in socket and bisocket transports.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ More flexible configuration (see <classname>org.jboss.remoting.Remoting</classname>.<constant>CONFIG_OVERRIDES_LOCATOR</constant>).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
Added immediate shutdown option for socket transport.
</para>
</listitem>
@@ -468,7 +469,7 @@
</listitem>
<listitem>
<para>
- More flexible configuration (see <package>org.jboss.remoting</package>.<classname>Client</classname>.<constant>USE_ALL_PARAMS</constant>).
+ More flexible configuration (see <classname>org.jboss.remoting.Client</classname>.<constant>USE_ALL_PARAMS</constant>).
</para>
</listitem>
<listitem>
@@ -549,7 +550,7 @@
<para>Servers can be bound to multiple IP addresses.</para>
</listitem>
<listitem>
- <para>Servers can run in the presence of a security manager.</para>
+ <para>Clients and servers can run in the presence of a security manager.</para>
</listitem>
<listitem>
<para>Greater configurability.</para>
More information about the jboss-cvs-commits
mailing list