*** empty log message ***

7 files changed, 55 insertions, 38 deletions

diff --git a/docs/tutorials/001/Source.tgz b/docs/tutorials/001/Source.tgz
index 5f7392a7fc8..d88891aaf22 100644
--- a/docs/tutorials/001/Source.tgz
+++ b/docs/tutorials/001/Source.tgz
diff --git a/docs/tutorials/001/acceptor.h b/docs/tutorials/001/acceptor.h
index 094e68acdf5..2556f0ab324 100644
--- a/docs/tutorials/001/acceptor.h
+++ b/docs/tutorials/001/acceptor.h
@@ -33,9 +33,6 @@
  */
 class Logging_Acceptor : public ACE_Event_Handler
 {
-
-friend class Logging_Handler;
-
 public:
 
   /*
@@ -96,9 +93,18 @@ private:
     When an accept request arrives, the reactor will invoke the handle_input()
     callback.  This is where we deal with the connection request.
    */
-  int handle_input (ACE_HANDLE)
+  virtual int handle_input (ACE_HANDLE _handle)
   {
     /*
+      The handle provided to us by the reactor is the one that triggered
+      our up-call.  In some advanced situations, you might actually
+      register a single handler for multiple connections.  The _handle
+      parameter is a way to sort 'em out.  Since we don't use that
+      here, we simply ignore the parameter with the ACE_UNUSED_ARG() macro.
+     */
+    ACE_UNUSED_ARG(_handle);
+
+    /*
       In response to the connection request, we create a new Logging_Handler.
       This new object will be used to interact with the client until it
       disconnects.
diff --git a/docs/tutorials/001/logger.h b/docs/tutorials/001/logger.h
index 33cb20678ad..46ed9fa2d02 100644
--- a/docs/tutorials/001/logger.h
+++ b/docs/tutorials/001/logger.h
@@ -89,7 +89,7 @@ protected:
   /*
     And here's the handle_input().  This is really the workhorse of the application.
    */
-  int handle_input (ACE_HANDLE)
+  virtual int handle_input (ACE_HANDLE)
   {
     /*
       Create and initialize a small receive buffer.
@@ -109,16 +109,16 @@ protected:
       Notice that in the error case or closed case we return -1.  That tells the reactor
       to call our handle_close() where we'll take care of shutting down cleanly.
 
-			Although we don't make use of them, there are additional parameters you can
-			use with the recv() call.  One of these is an ACE_Time_Value that allows you to
-			limit the amount of time blocking on the recv().  You would use that if you
-			weren't sure if data was available.  Since we only get to handle_input() when
-			data is ready, that would be redundant.  On the other hand, if you use recv_n()
-			to read *exactly* a number of bytes then limiting the time you wait for those
-			bytes might be good.
-			The other paramter that may come in handy is an integer <i>flags</i>.  This is
-			passed directly to the underlying OS recv() call.  See the man page recv(2)
-			and the header sys/socket.h for the gory details.
+      Although we don't make use of them, there are additional parameters you can
+      use with the recv() call.  One of these is an ACE_Time_Value that allows you to
+      limit the amount of time blocking on the recv().  You would use that if you
+      weren't sure if data was available.  Since we only get to handle_input() when
+      data is ready, that would be redundant.  On the other hand, if you use recv_n()
+      to read *exactly* a number of bytes then limiting the time you wait for those
+      bytes might be good.
+      The other paramter that may come in handy is an integer <i>flags</i>.  This is
+      passed directly to the underlying OS recv() call.  See the man page recv(2)
+      and the header sys/socket.h for the gory details.
      */
     switch( this->cli_stream_.recv(buf,sizeof buf) )
     {
diff --git a/docs/tutorials/001/page03.html b/docs/tutorials/001/page03.html
index cd01afd2548..1b838d61bbd 100644
--- a/docs/tutorials/001/page03.html
+++ b/docs/tutorials/001/page03.html
@@ -66,9 +66,6 @@ appropriate section (event_handler) which would cater to his needs.
  */
 class Logging_Acceptor : public ACE_Event_Handler
 {
-
-friend class Logging_Handler;
-
 public:
 
   /*
@@ -129,9 +126,18 @@ private:
     When an accept request arrives, the reactor will invoke the handle_input()
     callback.  This is where we deal with the connection request.
    */
-  int handle_input (ACE_HANDLE)
+  virtual int handle_input (ACE_HANDLE _handle)
   {
     /*
+      The handle provided to us by the reactor is the one that triggered
+      our up-call.  In some advanced situations, you might actually
+      register a single handler for multiple connections.  The _handle
+      parameter is a way to sort 'em out.  Since we don't use that
+      here, we simply ignore the parameter with the ACE_UNUSED_ARG() macro.
+     */
+    ACE_UNUSED_ARG(_handle);
+
+    /*
       In response to the connection request, we create a new Logging_Handler.
       This new object will be used to interact with the client until it
       disconnects.
diff --git a/docs/tutorials/001/page04.html b/docs/tutorials/001/page04.html
index 5472a3dec49..be4742ae2ce 100644
--- a/docs/tutorials/001/page04.html
+++ b/docs/tutorials/001/page04.html
@@ -106,7 +106,7 @@ protected:
   /*
     And here's the handle_input().  This is really the workhorse of the application.
    */
-  int handle_input (ACE_HANDLE)
+  virtual int handle_input (ACE_HANDLE)
   {
     /*
       Create and initialize a small receive buffer.
@@ -126,16 +126,16 @@ protected:
       Notice that in the error case or closed case we return -1.  That tells the reactor
       to call our handle_close() where we'll take care of shutting down cleanly.
 
-			Although we don't make use of them, there are additional parameters you can
-			use with the recv() call.  One of these is an ACE_Time_Value that allows you to
-			limit the amount of time blocking on the recv().  You would use that if you
-			weren't sure if data was available.  Since we only get to handle_input() when
-			data is ready, that would be redundant.  On the other hand, if you use recv_n()
-			to read *exactly* a number of bytes then limiting the time you wait for those
-			bytes might be good.
-			The other paramter that may come in handy is an integer <i>flags</i>.  This is
-			passed directly to the underlying OS recv() call.  See the man page recv(2)
-			and the header sys/socket.h for the gory details.
+      Although we don't make use of them, there are additional parameters you can
+      use with the recv() call.  One of these is an ACE_Time_Value that allows you to
+      limit the amount of time blocking on the recv().  You would use that if you
+      weren't sure if data was available.  Since we only get to handle_input() when
+      data is ready, that would be redundant.  On the other hand, if you use recv_n()
+      to read *exactly* a number of bytes then limiting the time you wait for those
+      bytes might be good.
+      The other paramter that may come in handy is an integer <i>flags</i>.  This is
+      passed directly to the underlying OS recv() call.  See the man page recv(2)
+      and the header sys/socket.h for the gory details.
      */
     switch( this->cli_stream_.recv(buf,sizeof buf) )
     {
@@ -196,13 +196,12 @@ protected:
 <P>
 <HR WIDTH="100%">
 
-<P>Now that we know how to accept a connection request, let's move on to
-the next page where we learn how to handle the actual connection. Even
-though we just learned about this cool template thing, we will continue
-to use the "hand-written" acceptor developed above. As I mentioned, the
-only difference will be in the <I>open</I> function of the connection handler
-anyway.
-
+<P>
+The comments really should tell the story.  The really
+interesting stuff is in <i>handle_input()</i>.  Everything
+else is just housekeeping.
+In the future, we'll learn about ACE_Svc_Handler&lt;>
+which will take care of most of the housekeeping for us.
 <P>
 <HR WIDTH="100%">
 <CENTER></CENTER>
diff --git a/docs/tutorials/001/page05.html b/docs/tutorials/001/page05.html
index 5e441d04b11..b242b31406c 100644
--- a/docs/tutorials/001/page05.html
+++ b/docs/tutorials/001/page05.html
@@ -51,6 +51,12 @@ handler</A></LI>
 or the Unix command <I>tar -xvzf filename</I>.)
 
 <P>
+To read more about the patterns used in this example (as well as
+quite a few which aren't!), you should check out
+<A HREF="http://www.cs.wustl.edu/~schmidt/patterns-ace.html">http://www.cs.wustl.edu/~schmidt/patterns-ace.html.</A>
+In fact, it's probably safe to say that the concepts found there will keep
+coming back to haunt you as these tutorials continue.
+<P>
 <HR WIDTH="100%">
 <CENTER></CENTER>
 
diff --git a/docs/tutorials/001/server.cpp b/docs/tutorials/001/server.cpp
index 391b1c18825..412f43a9a34 100644
--- a/docs/tutorials/001/server.cpp
+++ b/docs/tutorials/001/server.cpp
@@ -30,7 +30,7 @@ ACE_Reactor * g_reactor;
 */
 static const u_short PORT = ACE_DEFAULT_SERVER_PORT;
 
-int main (int, char **)
+int main (int, char *[])
 {
   /*
     Create a Reactor instance.  Again, a global pointer isn't exactly the