avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Engstrom" <Erik.Engst...@dot.state.mn.us>
Subject [PATCH] altrmi xdocs typos
Date Thu, 12 Dec 2002 05:10:14 GMT
Fixed some typos as I read through the documentation, if this is usefull I will post more as
I dig deeper.  By the way the link for the graphic in facades.xml is broken.  Can anyone tell
me how to fix it?

Thanks for such a cool project.

Erik

Index: connection-listeners.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/connection-listeners.xml,v
retrieving revision 1.2
diff -u -r1.2 connection-listeners.xml
--- connection-listeners.xml	26 Jul 2002 16:21:36 -0000	1.2
+++ connection-listeners.xml	12 Dec 2002 04:51:38 -0000
@@ -10,9 +10,9 @@
   <body>
     <s1 title="Introduction">
       <p>
-        Conenction listener can monitor each method invokation (affects performance) 
+        A conenction listener can monitor each method invocation (affects performance) 
         and handle service suspensions and abnormal ends.  The connection listener 
-        can decide how to do the reconnection andhow to obey the susepension.  In 
+        can decide how to do the reconnection and how to obey the suspension.  In 
         theory a method call can just be left blocking until the servce is 
         reconnected (after abend) or resumed after suspension.  Connection listeners
         run on the client side.
Index: facades.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/facades.xml,v
retrieving revision 1.2
diff -u -r1.2 facades.xml
--- facades.xml	26 Jul 2002 16:21:36 -0000	1.2
+++ facades.xml	12 Dec 2002 04:51:38 -0000
@@ -10,13 +10,13 @@
   <body>
     <s1 title="Introduction">
       <p>
-        AltRMI publishes objects via their interfaces.  It does not replicate all objects

-        on the lient side, it generates proxies for those defines as facades.
+        AltRMI publishes an object via its interface.  It does not replicate the object 
+        on the client side, it generates a proxy for it defined as a facade.
       </p>
     </s1>          
     <s1 title="Facades">
       <p>                
-        Consider a whether system that models weather stations (fixed and mobile) and 
+        Consider a system that models weather stations (fixed and mobile) and 
         the meterologists that staff the stations.....
       </p>
       <figure>
@@ -24,12 +24,12 @@
         <graphic srccredit="Paul Hammant, 2002" fileref="images/facades.jpg" format="JPEG"/>
       </figure>   
       <p>
-        The interfaces and the class on the right of the right of the green line are 'interface'

+        The interfaces and the class on the right of the green line are 'interface' 
         or API, and we want them to exist as is on the client side for general use.  Things
on the 
-        left are the implementation classes and they exist on theserver side only.  Though
not 
-        shown here, it would be easiest to have them is a seperate package.  Representing
those 
-        objects on the client side are generated proxies.  Those proxies are pass-by-reference
-        boudaries but are castable to any of the interfaces they represent.  There is one

+        left are the implementation classes and they exist on the server side only.  Though
not 
+        shown here, it would be easiest to have them in a seperate package.  Representing
those 
+        objects on the client side are generated proxies.  Proxies are pass-by-reference
+        boundaries but are castable to any of the interfaces they represent.  There is one

         pass-by-value object and that is Coordinate.  It should be serializable and final

         (Immutable pattern).        
       </p>  
@@ -39,7 +39,7 @@
         'WeatherSystem' or 'WeatherSystem_1.0' etc.
       </p>      
       <>  
-        Once the client has a handle on the WetherSystem normal Java tarversals are possibleL
+        Once the client has a handle on the WetherSystem, normal Java traversals are possible
 <source>
 WeatherSystem ws = getWeatherSystem(); // some thing that does the JNDI lookup.
 // yes we know the following could throw NPEs or Array Index issues.
Index: generating-proxies.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/generating-proxies.xml,v
retrieving revision 1.3
diff -u -r1.3 generating-proxies.xml
--- generating-proxies.xml	26 Jul 2002 16:21:36 -0000	1.3
+++ generating-proxies.xml	12 Dec 2002 04:51:38 -0000
@@ -10,7 +10,7 @@
   <body>
     <s1 title="Introduction">
       <p>
-        You can choose to generate your procies in advance of use, or to defer generation

+        You can choose to generate your proxies in advance of use, or to defer generation

         until runtime.  As the generation requires javac in tools.jar (multi megabyte), you

         have to decide whether your runtime environment or distribution can support or 
         legally distribute it.
Index: otherfeatures.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/otherfeatures.xml,v
retrieving revision 1.3
diff -u -r1.3 otherfeatures.xml
--- otherfeatures.xml	26 Jul 2002 16:21:36 -0000	1.3
+++ otherfeatures.xml	12 Dec 2002 04:51:38 -0000
@@ -21,7 +21,7 @@
         <p>
           Classes providing client side implementation of the transported 
 	  interface(s) can be either on the client side or the server side (and 
-	  duly transported) at time of lookup.  On the server side, the proxy classes
+	  duly transported) at the time of lookup.  On the server side, the proxy classes
           can be generated in advance (Ant Task) or at runtime - javac is invoked.
         </p>
       </s2>
@@ -35,7 +35,7 @@
      </s2>
       <s2 title="Suspendable/Resumable service.">            
         <p>
-          The Server supports suspend() and resume().  With the current impl this 
+          The Server supports suspend() and resume().  With the current implimentation this

 	  replies in a timely fashion to the client that the client should try
 	  later.  The client waits for the notified amount of time and seamlessly
 	  tries the request again.  A server could cycle through suspended and back
@@ -87,7 +87,7 @@
       <s2 title="No duplicate instances.">            
         <p>
           For Facades, if you call Person p = getPerson("Fred") twice you will get 
-	  the same instance on the client side is it is the same instance on the 
+	  the same instance on the client side if it is the same instance on the 
           server side.        
         </p>
       </s2>
Index: pingers.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/pingers.xml,v
retrieving revision 1.3
diff -u -r1.3 pingers.xml
--- pingers.xml	26 Jul 2002 16:21:36 -0000	1.3
+++ pingers.xml	12 Dec 2002 04:51:38 -0000
@@ -11,8 +11,8 @@
     <s1 title="Introduction">
       <p>
         Although it may not be necessary for all types of transport, 
-        there is a mechanism called a pinger that can be used to keep alive 
-        the connection. Pingers run on the client side.
+        there is a mechanism called a pinger that can be used to keep 
+        the connection alive. Pingers run on the client side.
       </p>
     </s1>          
     <s1 title="Pinger Interface">
@@ -28,11 +28,11 @@
       </p>
       <s2 title="DefaultConnectionPinger">
         <p>
-          This pinger pings every ten seconds, but stops one hundred seconds seoonds
+          This pinger pings every ten seconds, but stops one hundred seconds
           after the last real request.  The 10 &amp; 100 are configurable of cours.
         </p>
         <p> 
-          This pinger is the default and will be used if none other is 
+          This pinger is the default and will be used if no other is 
           specified.
         </p>        
       </s2>
Index: publishing.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/publishing.xml,v
retrieving revision 1.2
diff -u -r1.2 publishing.xml
--- publishing.xml	26 Jul 2002 16:21:36 -0000	1.2
+++ publishing.xml	12 Dec 2002 04:51:38 -0000
@@ -10,16 +10,16 @@
   <body>
     <s1 title="Introduction">
       <p>
-        Publishing is an server responsibility obviously.  It is quite straight forward.
+        Publishing is a server responsibility, it is quite straight forward.
       </p>
     </s1>          
     <s1 title="Publishing">
       <p>                
-        You have to choose your server, publish the impl (reiterating the interfaces that
will 
+        You have to choose your server, publish the implimentation (reiterating the interfaces
that will 
         be pass-by-reference boundaries), then start the server.....
 <source>
 <![CDATA[
-        AbstractServer as new CompleteSocketCustomStreamServer(1235);
+        AbstractServer as = new CompleteSocketCustomStreamServer(1235);
         TestInterfaceImpl ti = new TestInterfaceImpl();
         as.publish(ti, "Hello", new PublicationDescription(TestInterface.class, TestInterface2.class));
         as.start();
Index: transports.xml
===================================================================
RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/xdocs/transports.xml,v
retrieving revision 1.5
diff -u -r1.5 transports.xml
--- transports.xml	26 Jul 2002 16:21:36 -0000	1.5
+++ transports.xml	12 Dec 2002 04:51:39 -0000
@@ -24,8 +24,8 @@
         Avalon-Phoenix or or an implementation of the EJB specification will.
       </p>
       <p>
-        All of these transports are ynchronous too.  That means that an invokation acorss
there connection
-        will wait until the it is completed server side before the next invocation is allowed
through.
+        All of these transports are synchronous too.  That means that an invocation across
the connection
+        will wait until it is completed on the server side before the next invocation is
allowed through.
       </p>
 
       <s2 title="Plain Sockets / ObjectStream &amp; CustomStream varients">
@@ -42,7 +42,7 @@
       </s2>
       <s2 title="Over RMI">
         <p>
-          This is another transport that bridges two different JVMs using TCP/IP.  It is
actually the fstest of all the
+          This is another transport that bridges two different JVMs using TCP/IP.  It is
actually the fastest of all the
           TCP/IP using transports. and takes advantage of RMI as it's transport while hiding
RMI from the AltRMI
           client and server.
         </p>
@@ -50,18 +50,18 @@
       <s2 title="Piped with same VM / ObjectStream &amp; CustomStream varients">
         <p>
           In a similar way to the ObjectStream and CustomStream implementations of the plain
sockets transport, these
-          offer trasport using a pipe inside the JVM.  Not needed for most users of AltRMI
these prove useful for
+          offer transport using a pipe inside the JVM.  Not needed for most users of AltRMI
these prove useful for
           developers making complex trees of classloaders with high separation from each
other. As a Pipe is being
-          used there is is some opportunity for buffering of invokations.  This might slow
the throughput down but
-          this may releieve other parts of a particular design.
+          used there is is some opportunity for buffering of invocations.  This might slow
the throughput down but
+          this may relieve other parts of a particular design.
         </p>
       </s2>
       <s2 title="Direct within same VM">
         <p>
           There are 'Dirct' and 'DirectMarshalled' transports.  These are use useful in the
same scenarios as
-          the Piped one, but with some small differences.  Principally, there is no pipe
- the invokation is
+          the Piped one, but with some small differences.  Principally, there is no pipe
- the invocation is
           immediately handled on the server side.  With Direct there is also the fact that
all mutually visible
-          classes and interfaces woould have to be in a commonly visible classloader.  With
DirectMarshalled,
+          classes and interfaces would have to be in a commonly visible classloader.  With
DirectMarshalled,
           there can be duplicate interfaces and class definitions as in the streamed types
of transport.
         </p>
       </s2>
@@ -74,11 +74,11 @@
     </s1>
     <s1 title="Supplied Callback capable Transports">
       <p>
-        All of these transports are asynchronous.  Thais means that an invokation across
there connection
-        will does not wait until the reply is ready before it allows another request though.
 This allows
-        two thing - excpetionally lengthy requests (that might ordinarily affect timeouts)
to be performed and
-        callbacks (server invoking requests on the client).  There is a smal (15%) cost to
using this transport for
-        simple cases, but its benefits outweigh its deficiences.
+        All of these transports are asynchronous.  Thais means that an invocation across
the connection
+        does not wait until the reply is ready before it allows another request though. 
This allows
+        two things - excpetionally lengthy requests (that might ordinarily affect timeouts)
to be performed and
+        callbacks (server invoking requests on the client).  There is a small (15%) cost
to using this transport for
+        simple cases, but its benefits outweigh its deficiencies.
       </p>
       <p>
         Whilst the Callback enabled transports are better from the point of view of asynchronous
behaviour
@ -123,8 +123,8 @@
 	    <s2 title="AltRMI types in the same VM">
 	    <p>
 
-	    These are useful for complete classloader separation of interface &amp; impl using
-	    different classloaders. Impl and 'remote' proxy do not need to see the same
+	    These are useful for complete classloader separation of interface &amp; implementaion
using
+	    different classloaders. The implementation and 'remote' proxy do not need to see the
same
             interfaces etc..<br/>
             <br/>
 	    Speed Test type                   Count Relative<br/>
@@ -146,9 +146,9 @@
 	    <p>
 
 	    - In VM, without using AltRMI - for comparison.
-	    - The inteface, impl and proxy cannot be separated in terms of
+	    - The inteface, implementation and proxy cannot be separated in terms of
 	      branches of classloader for these three. The same interfaces
-	      etc must be visible to both impl and proxy.
+	      etc must be visible to both implementation and proxy.
 	      <br/>
 	    Speed Test type                   Count Relative<br/>
 	    ------------------------------- ------- --------<br/>
@@ -175,22 +175,22 @@
         <strong>void setObject(object o);</strong> and <strong>Object getObject();</strong>,
and clases in
         B amp; C could invoke those methods freely, the you might consider that B has a way
of taking to C.  if B
         called (essentially) <strong>A.setObject("Hello")</strong>, then C could
indeed call <strong>String
-        s = A.getObject()</strong> without ny problem.  Say a class being passed were
called 'Thing' and was in the
+        s = A.getObject()</strong> without any problem.  Say a class being passed were
called 'Thing' and was in the
         classloader of B and duplicated in the classloader of C, but not in A at all, then
it would not be passable
-        by the setter/getter mechanism outlined above.  Why?  The JVM considers then differnt
classes because they
+        by the setter/getter mechanism outlined above.  Why?  The JVM consders them different
classes because they
         are mounted in different classloaders (even though from the same source).  That is
a secret
         of classloading (at least as it pertains to RPC in one VM).
       </p>
       <p>
         The issue is relevent to AltRMI mostly if it is being used to connect two nodes of
a single classloader tree.
-        If the trasport chosen is 'Direct' then you will get ClassCastExceptions thrown by
the JVM if you had been
+        If the transport chosen is 'Direct' then you will get ClassCastExceptions thrown
by the JVM if you had been
         passed an Object you wanted to cast up to something, and that something were represented
by a class definition
         in both the server and client nodes of the classloader tree.  If the something class
were in a mutualy
         visible parent class loader then no issue would be apparent.  IF the client and server
were in seperate VMs,
-        then no issue would be apparent, princiapally because on the marchalling to serialized
form natly hides the
+        then no issue would be apparent, principally because the marshalling to serialized
form neatly hides the
         two class definitions from the JVM.  This is the clue to the solving of the issue
for a particular
-        client/server (in one JVM) confiuration you may be cooking up.  If you choose Piped
or DirectMarshalled as
-        trasnports, then you can have the same class definition in multiple classloader nodes.
 Of couse, both Piped
+        client/server (in one JVM) configuration you may be cooking up.  If you choose Piped
or DirectMarshalled as
+        transports, then you can have the same class definition in multiple classloader nodes.
 Of couse, both Piped
         and DirectMarshalled are slower than Direct as transports.  Configuration choices
for the developer/deployer.
       </p>
     </s1>

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message