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 & 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 & 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 & 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 &
impl using
- different classloaders. Impl and 'remote' proxy do not need to see the same
+ These are useful for complete classloader separation of interface &
+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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
