hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From k...@apache.org
Subject cvs commit: jakarta-hivemind/examples/src/documentation/content/xdocs/hivemind-examples calc.xml panorama.xml
Date Mon, 26 Jul 2004 19:07:11 GMT
knut        2004/07/26 12:07:11

  Modified:    examples/src/documentation/content/xdocs/hivemind-examples
                        calc.xml panorama.xml
  Log:
  corrected a few typos in the examples documentation.
  
  Revision  Changes    Path
  1.2       +3 -3      jakarta-hivemind/examples/src/documentation/content/xdocs/hivemind-examples/calc.xml
  
  Index: calc.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-hivemind/examples/src/documentation/content/xdocs/hivemind-examples/calc.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- calc.xml	24 Jul 2004 22:18:13 -0000	1.1
  +++ calc.xml	26 Jul 2004 19:07:11 -0000	1.2
  @@ -29,14 +29,14 @@
     <body>
   
   <p>
  -The calculator example demonstates the most basic concepts of HiveMind; the difference
  -between &create-instance; and &invoke-factory;, the the fact that services are,
by default, created only as needed,
  +The calculator example demonstrates the most basic concepts of HiveMind; the difference
  +between &create-instance; and &invoke-factory;, the fact that services are, by
default, created only as needed,
   and the ability of &hivemind.BuilderFactory; to automatically wire services together.
It also demonstrates the behavior of the
   &hivemind.LoggingInterceptor;.
   </p>
   
   <p>
  -After compiling the examples, you can use Ant to run examples:
  +After compiling the examples, you can use Ant to run them:
   </p>
   
   <source><![CDATA[bash-2.05b$ ant run-calculator
  
  
  
  1.3       +12 -12    jakarta-hivemind/examples/src/documentation/content/xdocs/hivemind-examples/panorama.xml
  
  Index: panorama.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-hivemind/examples/src/documentation/content/xdocs/hivemind-examples/panorama.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- panorama.xml	25 Jul 2004 22:12:51 -0000	1.2
  +++ panorama.xml	26 Jul 2004 19:07:11 -0000	1.3
  @@ -31,7 +31,7 @@
   Panorama is a disguised version of
   <link href="http://www.webct.com/">WebCT</link>'s <strong>Vista</strong>
application.  Vista is
   a truly massive web application, consisting of thousands of Java classes and JSPs and hundreds
of EJBs. Vista is
  -organized as a large number of somewhat inter-related <em>tools</em> with an
underlying substrate of <em>services</em>.
  +organized as a large number of somewhat interrelated <em>tools</em> with an
underlying substrate of <em>services</em>.
   In fact, HiveMind was originally created to manage the complexity of Vista.
   </p>   
   
  @@ -52,23 +52,23 @@
   </p>
   
   <p>
  -The <em>legacy</em>   version of Vista startup consisted of a WebLogic startup
class that invoked an 
  -central stateless session EJB. The startup EJB was responsible for performing all 40+ 
startup tasks ... typically
  +The <em>legacy</em> version of Vista startup consisted of a WebLogic startup
class that invoked a 
  +central stateless session EJB. The startup EJB was responsible for performing all 40+ startup
tasks ... typically
   by invoking a public static method of a class related to the tool.
   </p>
   
   <p>
   This was problematic for several reasons. It created a dependency on WebLogic to manage
startup (really, a minor consideration,
  -but one nonetheless). More importantly, it created an unneccessary binding between the
startup EJB and all the other code
  -in all the other tools. These unwanted dependencies created ripple effects throught the
code base that impacted
  +but one nonetheless). More importantly, it created an unnecessary binding between the startup
EJB and all the other code
  +in all the other tools. These unwanted dependencies created ripple effects throughout the
code base that impacted
   refactored efforts, and caused deployment problems that complicated the build (requiring
the duplication of
   many common classes inside the startup EJB's JAR, to resolve runtime classloader dependencies).
   </p>
   
   <note>
  -It's all about class loaders. The class loader that loaded the startup EJB didn't have
visibliity to the contents
  +It's all about class loaders. The class loader that loaded the startup EJB didn't have
visibility to the contents
   of the other EJB JARs deployed within the Vista EAR. To satisfy WebLogic's ejbc command
(EJB JAR packaging tool),
  -and to succesfully locate the classes at runtime, it was necessary duplicate many classes
from the other EJB JARs into the startup EJB JAR.
  +and to succesfully locate the classes at runtime, it was necessary to duplicate many classes
from the other EJB JARs into the startup EJB JAR.
   With HiveMind, this issue goes away, since the module deployment descriptors store the
class <em>name</em>, and the
   <em>servlet thread's context class loader</em> is used to resolve that name
... and <em>it</em> has visibility
   to all the classes in all the EJB JARs.
  @@ -83,15 +83,15 @@
   </p>  
   
   <p>
  -Each startup task would be given a unique id, a title and a set of <em>depencies</em>
(on other tasks). How
  +Each startup task would be given a unique id, a title and a set of <em>dependencies</em>
(on other tasks). How
   the task actually operated was left quite abstract ... with careful support for supporting
the existing legacy approach
  -(public static methods). What would change would be how these tasks were executed, 
  +(public static methods). What would change would be how these tasks were executed.
   </p>
   
   <p>
   The advantage of HiveMind is that each <em>module</em> can contribute as many
or as few startup tasks
   as necessary into the Startup configuration point as needed. This allows the startup logic
to be
  -properly <em>enapsulated</em> in the module. The startup logic can be easily
changed without affecting
  +properly <em>encapsulated</em> in the module. The startup logic can be easily
changed without affecting
   other modules, and without having to change any single contentious resource (such as the
legacy approach's
   startup EJB).
   </p>
  @@ -575,7 +575,7 @@
   is responsible for instantiating the core service implementation and setting its properties.
 In many cases,
   you will set the properties to mock objects ... HiveMind uses
   <link href="http://www.easymock.org/">EasyMock</link> extensively, and
  -provides a base class, <code>HiveMindTestCase</code>, that contains much support
for creating of Mock controls
  +provides a base class, <code>HiveMindTestCase</code>, that contains much support
for creating Mock controls
   and objects.
   </p>
   
  @@ -694,7 +694,7 @@
   </p>
   
   <p>
  -We create a Mock Log object, and check that the correct messages are logged int the correct
order.  Once
  +We create a Mock Log object, and check that the correct messages are logged in the correct
order.  Once
   we have set the expectations for all the EasyMock controls, we invoke <code>replayControls()</code>
and
   continue with our test.  The <code>verifyControls()</code> method ensures that
all mock objects
   have had all expected methods invoked on them.
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message