[jboss-cvs] JBossCache/docs/PojoCache/en/modules ...

Ben Wang bwang at jboss.com
Thu Oct 26 05:01:44 EDT 2006


  User: bwang   
  Date: 06/10/26 05:01:44

  Modified:    docs/PojoCache/en/modules      api.xml appendix.xml
                        architecture.xml instrumentation.xml
                        introduction.xml
  Log:
  upd
  
  Revision  Changes    Path
  1.4       +4 -4      JBossCache/docs/PojoCache/en/modules/api.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: api.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/api.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -b -r1.3 -r1.4
  --- api.xml	27 Sep 2006 04:56:44 -0000	1.3
  +++ api.xml	26 Oct 2006 09:01:44 -0000	1.4
  @@ -33,7 +33,7 @@
       */
      public static PojoCache createInstance(Configuration config, boolean start);
   </programlisting>
  -      <para>For example, to obtain a PojoCache instance and start the cache lifecycle automaticaly,
  +      <para>For example, to obtain a PojoCache instance and start the cache lifestyle automatically,
         we can do:
   <programlisting>
      String configFile = "META-INF/replSync-service.xml";
  @@ -59,7 +59,7 @@
   <programlisting>
      /**
       * Attach a POJO into PojoCache. It will also recursively put any sub-POJO into
  -    * the cache system. A POJO can be the following and have the consqeuences when attached:
  +    * the cache system. A POJO can be the following and have the consequences when attached:
       *
       * It is PojoCacheable, that is, it has been annotated with
       * {@see org.jboss.cache.aop.annotation.PojoCacheable} annotation (or via XML), and has
  @@ -68,7 +68,7 @@
       *
       * It is Serializable. The POJO will still be stored in the cache system. However, it is
       * treated as an "opaque" object per se. That is, the POJO will neither be intercepted
  -    * (for fine-grained operation) or object relantionship will be maintained.
  +    * (for fine-grained operation) or object relationship will be maintained.
       *
       * Neither of above. In this case, a user can specify whether it wants this POJO to be
       * stored (e.g., replicated or persistent). If not, a PojoCacheException will be thrown.
  @@ -77,7 +77,7 @@
       *             recommend the use of hierarchical String separating by a designated separator. Default
       *             is "/" but it can be set differently via a System property, jbosscache.separator
       *             in the future release. E.g., "ben", or "student/joe", etc.
  -    * @param pojo object to be inerted into the cache. If null, it will nullify the fqn node.
  +    * @param pojo object to be inserted into the cache. If null, it will nullify the fqn node.
       * @return Existing POJO or null if there is none.
       * @throws PojoCacheException Throws if there is an error related to the cache operation.
       */
  
  
  
  1.4       +1 -1      JBossCache/docs/PojoCache/en/modules/appendix.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: appendix.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/appendix.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -b -r1.3 -r1.4
  --- appendix.xml	27 Sep 2006 06:49:42 -0000	1.3
  +++ appendix.xml	26 Oct 2006 09:01:44 -0000	1.4
  @@ -8,7 +8,7 @@
            are:
            <literal>Person,</literal> <literal>Student,</literal>
            and
  -         <literal>Address</literal>. Below are their defintion
  +         <literal>Address</literal>. Below are their definition
            (note that
            neither class implements
            <literal>Serializable</literal>
  
  
  
  1.9       +7 -7      JBossCache/docs/PojoCache/en/modules/architecture.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: architecture.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/architecture.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -b -r1.8 -r1.9
  --- architecture.xml	27 Sep 2006 04:56:44 -0000	1.8
  +++ architecture.xml	26 Oct 2006 09:01:44 -0000	1.9
  @@ -11,7 +11,7 @@
         when a call comes in (e.g., <literal>attach</literal> or <literal>detach</literal>), it will go through
         the PojoCache interceptor stack first (configured from <literal>pojocache-aop.xml</literal> but is mostly
            read only). After that, it will store
  -      the POJO fields into Cache store and then JGroups (for state replication) as confgiured from a designated
  +      the POJO fields into Cache store and then JGroups (for state replication) as configured from a designated
         <literal>cache-service.xml</literal>. This architecture provides a decoupled framework that by itself
         is modularized and pluggable (available in the future).</para>
      <para>Please note that you will need to specify a system property <literal>jboss.aop.path</literal> to set it
  @@ -117,7 +117,7 @@
   </para><para>
            Note again that this
         customized interceptor stack is provided in <literal>pojocache-aop.xml</literal> where user can
  -      also add customed interceptor if needs to.</para>
  +      also add customized interceptor if needs to.</para>
   
      </sect1>
         <sect1>
  @@ -149,7 +149,7 @@
   
            <para>JBossAop has the capability to intercept both method level call and field level read write. From the
               perspective of PojoCache, field level interception is the appropriate mechanism to synchronize with
  -            the backend cache store. Please note that,
  +            the back-end cache store. Please note that,
               <itemizedlist>
                  <listitem>
                     the field level interception applies to all access qualifiers.
  @@ -587,13 +587,13 @@
            Keep in mind that a "Person" object would have sub-objects (such as <literal>Address</literal>)
            that we need to recursively map. This example is created from a two node replication group where
            one node is a Beanshell window and the other node is a Swing Gui window (shown here).
  -         For clarity, we have created couple snapshots to hightlight the mapping process.</para><para>
  +         For clarity, we have created couple snapshots to highlight the mapping process.</para><para>
            The following figure illustrates the first step of the mapping approach. From the bottom of the figure,
            we can see that
         the <literal>PojoReference</literal> field under <literal>pojo/joe</literal> is pointing to an
            internal location,
         <literal>/__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49n5o-2</literal>. That is, under user-specified
  -      Id string, we store only an indirect reference to the intneral area. Please note that
  +      Id string, we store only an indirect reference to the internal area. Please note that
            <literal>Mary</literal> has a similar reference. (Note that the <literal>_lock_</literal> is used
      to control POJO level transaction locking and is considered internal.)</para>
         <figure>
  @@ -670,7 +670,7 @@
         </figure>
   
         <para>Finally, clicking on the <literal>/__JBossInternal__/5c4o12-lpaf5g-esl49n5e-1-esl49ngs-3</literal> node
  -      again, we can see the primitive fields are stored there, e.g., <literal>Stree</literal>,
  +      again, we can see the primitive fields are stored there, e.g., <literal>Street</literal>,
         <literal>Zip</literal>, and <literal>City</literal>. This is illustrated in the following figure.</para>
         <figure>
            <title>Object cache mapping: Address fields</title>
  @@ -800,7 +800,7 @@
         <title>POJO requirement</title>
         <para>The POJO requirement for PojoCache are:
         <itemizedlist>
  -         <listitem>It does not require to implment <literal>Serializable</literal>, but it does require there is a
  +         <listitem>It does not require to implement <literal>Serializable</literal>, but it does require there is a
            no-arg constructor declared (can be private). This is needed such that during failover, it has a way
            to reconstruct the POJO.</listitem>
            <listitem>There are specific default behaviors for different modifiers as mentioned (<literal>static</literal>,
  
  
  
  1.4       +3 -3      JBossCache/docs/PojoCache/en/modules/instrumentation.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: instrumentation.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/instrumentation.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -b -r1.3 -r1.4
  --- instrumentation.xml	27 Sep 2006 06:49:42 -0000	1.3
  +++ instrumentation.xml	26 Oct 2006 09:01:44 -0000	1.4
  @@ -195,7 +195,7 @@
                  </para>
                  <para>
                     The second one is <code>@org.jboss.cache.pojo.annotation.Serializable</code>, when applied to a field
  -                  varaiable, PojoCache will treat this variable as <code>Serializable</code>, even when it is
  +                  variable, PojoCache will treat this variable as <code>Serializable</code>, even when it is
                     <code>PojoCacheable</code>. However, the field will need to implement the <code>Serializable</code>
                     interface such that it can be replicated.
                  </para>
  @@ -214,7 +214,7 @@
                  Then when we do:
   <programlisting>
      Gadget gadget = new Gadget();
  -   Resource resource = new Resouce();
  +   Resource resource = new Resource();
      SepcialAddress specialAddress = new SpecialAddress();
   
      // setters
  @@ -224,7 +224,7 @@
      cache1.putObject("/gadget", gadget); // put into PojoCache management
   
      Gadget g2 = (Gadget)cache2.getObject("/gadget"); // retrieve it from another cache instance
  -   g2.getResource(); // This is should be null becuase of @Transient tag so it is not replicated.
  +   g2.getResource(); // This is should be null because of @Transient tag so it is not replicated.
   
      SepcialAddress d2 = g2.getSpecialAddress();
      d2.setName("inet"); // This won't get replicated automatically because of @Serializable tag
  
  
  
  1.5       +1 -1      JBossCache/docs/PojoCache/en/modules/introduction.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: introduction.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/PojoCache/en/modules/introduction.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -b -r1.4 -r1.5
  --- introduction.xml	26 Sep 2006 16:24:20 -0000	1.4
  +++ introduction.xml	26 Oct 2006 09:01:44 -0000	1.5
  @@ -84,7 +84,7 @@
               replication vs. coarse-grained one in a generic cache library like Cache.</listitem>
               <listitem> the object relationship and identity are preserved automatically in a distributed,
               replicated environment. It enables transparent usage behavior and increases software performance.</listitem>
  -            <listitem>Once the POJO is attached to the cache system, all subsquent POJO operation will trigger
  +            <listitem>Once the POJO is attached to the cache system, all subsequent POJO operation will trigger
               the replication or persistency automatically.
   <programlisting>POJO pojo = new POJO();
   pojoCache.attach("id", pojo);
  
  
  



More information about the jboss-cvs-commits mailing list