hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: jakarta-hivemind/src/documentation/content/xdocs services.xml
Date Wed, 27 Oct 2004 13:59:38 GMT
knut        2004/10/27 06:59:38

  Modified:    src/documentation/content/xdocs services.xml
  fixed some typos and made some tiny clarifications
  Revision  Changes    Path
  1.11      +14 -14    jakarta-hivemind/src/documentation/content/xdocs/services.xml
  Index: services.xml
  RCS file: /home/cvs/jakarta-hivemind/src/documentation/content/xdocs/services.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- services.xml	27 Oct 2004 13:23:49 -0000	1.10
  +++ services.xml	27 Oct 2004 13:59:38 -0000	1.11
  @@ -29,7 +29,7 @@
   			interface (packaged as part of a module). You supply the core
   			implementation of the interface (in the same module, or in a different
   			module). At runtime, HiveMind puts it all together.</p>
  -		<p>HiveMind uses four service models: primitive, singleton, threaded and
  +		<p>HiveMind defines four service models: primitive, singleton, threaded and
   			pooled. In the primitive and singleton models, each service will
   			ultimately be just a single object instance. In the threaded and pooled
   			models, there may be many instances simultaneously, one for each thread.</p>
  @@ -37,7 +37,7 @@
   			always local to the same JVM. Unlike XML-based web services, there's no
   			concept of language transparency: services are always expressed in terms
   			of Java interfaces. Unlike JMX or Jini, there's no concept of hot-loading
  -			of of services. HiveMind is kept delibrately simple, yet still very
  +			of services. HiveMind is kept deliberately simple, yet still very
   			powerful, so that your code is kept simple.</p>
   			<title>Defining Services</title>
  @@ -53,7 +53,7 @@
   				needed; in most cases, the service implementation is an additional Java
   				class which implements the service interface. HiveMind will instantiate
   				the class and configure it as needed. The exact timing is determined
  -				from the service's service model:</p>
  +				by the service implementation's service model:</p>
   				<li><strong>primitive</strong> : the service is constructed on first
  @@ -80,7 +80,7 @@
   				object that implements the service interface) and, optionally, any
   				number of interceptors. Interceptors sit between the core implementation
   				and the client, and add functionality to the core implementation such as
  -				logging, security, transaction demarkation or performance monitoring.
  +				logging, security, transaction demarcation or performance monitoring.
   				Interceptors are yet more objects that implement the service interface.</p>
   			<p>Instantiating the core service implementation, configuring it, and
   				wrapping it with any interceptors is referred to as <em>constructing the
  @@ -142,18 +142,18 @@
   					factory creates an instance that logs entry and exit to each method.</p>
   				<p>The factory shouldn't care what the service interface itself is ...
   					it should adapt to whatever interface is defined by the service
  -					extension point it will create an instance for.</p>
  +					extension point it will create an interceptor for.</p>
   				<p>A service extension point may have any number of interceptor
   					contributions. If the order in which interceptors are applied is
   					important, then the optional <code>before</code> and <code>after</code>
   					attributes can be specified.</p>
   				<figure src="images/InterceptorStack.png" alt="A Stack of Interceptors"
  -				<p>In this example, is was desired that any method logging occur first,
  +				<p>In this example, it was desired that any method logging occur first,
   					before the other interceptors. This ensures that the time taken to log
   					method entry and exit is not included in the performance statistics
   					(gathered by the performance interceptor). To ensure that the logging
  -					interceptor is the first, or earliest, interceptor, the special value 
  +					interceptor is the first, or earliest interceptor, the special value 
   					<code>*</code> (rather than a list of interceptor service ids) is
   					given for its <code>before</code> attribute (within the &interceptor;

   					element). This forces the logging interceptor to the front of the list
  @@ -164,7 +164,7 @@
   					falls between the two.</p>
   				<p>This is about as complex as an interceptor stack is likely to grow.
   					However, through the use of explicit dependencies, almost any
  -					arraingment of interceptors is possible ... even when different
  +					arrangement of interceptors is possible ... even when different
   					modules contribute the interceptors.</p>
   				<p>Interceptors implement the <code>toString()</code> method to provide
   					a useful identification for the interceptor, for example: <br/> 
  @@ -244,9 +244,9 @@
   			<p>Another module may provide an interceptor:</p>
   <?xml version="1.0"?>
  -<module id="com.myco.anotherpackage version="1.0.0">
  +<module id="com.myco.anotherpackage" version="1.0.0">
     <implementation service-id="com.myco.mypackage.Adder">
  -    <interceptor service-id="hivemind.LoggingInterceptor">
  +    <interceptor service-id="hivemind.LoggingInterceptor"/>
  @@ -265,7 +265,7 @@
   				(some of which may also be services), and building the stack of
   				interceptors for the service. Although HiveMind encourages you to define
   				your application in terms of a large number of small, simple, testable
  -				services, it is also desirable to avoid a cascade of unneccesary object
  +				services, it is also desirable to avoid a cascade of unnecessary object
   				creation due to the dependencies between services.</p>
   			<p>To resolve this, HiveMind defers the actual creation of services by
   				default. This is controled by the <code>model</code> attribute of the 
  @@ -289,7 +289,7 @@
           constructed on first reference. This is appropriate for services such as service
factories and interceptor 
           factories, and for several of the basic services provided in the <link 
           href="&hivedoc;/module/hivemind.html">hivemind module</link>.</p>
  -      <p> There is rarely a need use this service model in your own code. It exists
primarily to support the 
  +      <p> There is rarely a need to use this service model in your own code. It exists
primarily to support the 
           services in the hivemind module itself (the implementation of the singleton service
model is dependent on 
           several services that use the primitive service model). </p>
  @@ -375,7 +375,7 @@
   				listener</em> of events produced by some other service.</p>
   			<p>The producing service must include a matched pair of listener
   				registration methods, i.e., both <code>addFooListener()</code> and 
  -				<code>removeFooListener</code>. Note that only the <em>implementation
  +				<code>removeFooListener()</code>. Note that only the <em>implementation
   				class</em> must implement the listener interface; the service interface
   				does not have to extend the listener interface. The core service
   				implementation is registered directly with the producer service,
  @@ -404,7 +404,7 @@
   					<strong>What if I need to do some initializations in my service?</strong>
   					<p>If you have additional initializations that can't occur inside your
  -						core service implementations constructor (for instance, if the
  +						core service implementation's constructor (for instance, if the
   						initializations are based on properties set after the service
   						implementation object is instantiated), then your class should use
   						the &hivemind.BuilderFactory; to invoke an initializer method.</p>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message