[jboss-cvs] JBossAS SVN: r76873 - projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sun Aug 10 22:15:59 EDT 2008
Author: irooskov at redhat.com
Date: 2008-08-10 22:15:59 -0400 (Sun, 10 Aug 2008)
New Revision: 76873
Modified:
projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Architecture.xml
projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Instrumentation.xml
projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Introduction.xml
projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Term.xml
Log:
updated these files for cache pjo book so taht the work aspectized does not appear
Modified: projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Architecture.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Architecture.xml 2008-08-11 01:59:48 UTC (rev 76872)
+++ projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Architecture.xml 2008-08-11 02:15:59 UTC (rev 76873)
@@ -13,7 +13,7 @@
</para>
<sect1 id="Architecture-Dynamic_AOP_interception"><title>Dynamic AOP interception</title>
<para>
- JBossAop provides an API (<literal>appendInterceptor</literal>) to add an interceptor at runtime. PojoCache uses this feature extensively to provide user transparency. Every "aspectized" POJO class will have an associated <literal>org.jboss.aop.InstanceAdvisor</literal> instance. During a <literal>putObject(FQN fqn, Object pojo)</literal> operation (API explained below), PojoCache will examine to see if there is already a <literal>org.jboss.cache.aop.CacheInterceptor</literal> attached. (Note that a <literal>CacheInterceptor</literal> is the entrance of PojoCache to dynamically manage cache contents.) If it has not, one will be added to <literal>InstanceAdvisor</literal> object. Afterward, any POJO field modification will invoke the corresponding <literal>CacheInterceptor</literal> instance. Below is a schematic illustration of this process.
+ JBossAop provides an API (<literal>appendInterceptor</literal>) to add an interceptor at runtime. PojoCache uses this feature extensively to provide user transparency. Every Aspect-Oreinted Programming (AOP) created POJO class will have an associated <literal>org.jboss.aop.InstanceAdvisor</literal> instance. During a <literal>putObject(FQN fqn, Object pojo)</literal> operation (API explained below), PojoCache will examine to see if there is already a <literal>org.jboss.cache.aop.CacheInterceptor</literal> attached. (Note that a <literal>CacheInterceptor</literal> is the entrance of PojoCache to dynamically manage cache contents.) If it has not, one will be added to <literal>InstanceAdvisor</literal> object. Afterward, any POJO field modification will invoke the corresponding <literal>CacheInterceptor</literal> instance. Below is a schematic illustration of this process.
</para>
<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, <itemizedlist>
@@ -134,12 +134,12 @@
tree.startService(); // kick start tree cache
tree.putObject("/aop/joe", joe); // add aop sanctioned object (and sub-objects) into cache.
-// since it is aspectized, use of plain get/set methods will take care
+// since it is created using AOP, use of plain get/set methods will take care
// of cache contents automatically.
joe.setAge(41);
</programlisting>
<para>
- Note that a typical <literal>PojoCache</literal> usage involves instantiating the <literal>PojoCache</literal> , configuring, and starting the cache instance. Then, a user creates the aspectized POJO that will be put into the cache using <literal>putObject()</literal> API.
+ Note that a typical <literal>PojoCache</literal> usage involves instantiating the <literal>PojoCache</literal> , configuring, and starting the cache instance. Then, a user creates the AOP POJO that will be put into the cache using <literal>putObject()</literal> API.
</para>
<para>
In addition, PojoCache also supports get/set with parameter type of some <literal>Collection</literal> classes (i.e., <literal>List</literal> , <literal>Map</literal> , and <literal>Set</literal> ) automatically. For example, the following code snippet in addition to the above example will trigger PojoCache to manage the states for the <literal>Languages</literal> list as well. The following figure illustrates the node structure from the replicated GUI point of view. Details of Collection class support will be given later.
@@ -270,7 +270,7 @@
</programlisting>
</sect1><sect1 id="Architecture-Collection_class_proxy"><title>Collection class proxy</title>
<para>
- The POJO classes that inherit from <literal>Set</literal> , <literal>List</literal> , and <literal>Map</literal> are treated as "aspectized" automatically. That is, users need not declare them "prepared" in the xml configuration file or via annotation. Since we are not allowed to instrument the Java system library, we will use a proxy approach instead. That is, when we encounter any Collection instance, we will: <itemizedlist>
+ The POJO classes that inherit from <literal>Set</literal> , <literal>List</literal> , and <literal>Map</literal> are treated as AOP created automatically. That is, users need not declare them "prepared" in the xml configuration file or via annotation. Since we are not allowed to instrument the Java system library, we will use a proxy approach instead. That is, when we encounter any Collection instance, we will: <itemizedlist>
<listitem>
<para>Create a Collection proxy instance and place it in the cache (instead of the original reference). The mapping of the Collection elements will still be carried out recursively as expected.</para>
</listitem>
Modified: projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Instrumentation.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Instrumentation.xml 2008-08-11 01:59:48 UTC (rev 76872)
+++ projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Instrumentation.xml 2008-08-11 02:15:59 UTC (rev 76873)
@@ -34,7 +34,7 @@
</aop>
</programlisting>
<para>
- Detailed semantics of <literal>jboss-aop.xml</literal> can again be found in JBossAop. But above statements basically declare all field read and write operations in classes <code>Address</code> and <code>Person</code> will be "prepared" (or "aspectized"). Note that:
+ Detailed semantics of <literal>jboss-aop.xml</literal> can again be found in JBossAop. But above statements basically declare all field read and write operations in classes <code>Address</code> and <code>Person</code> will be "prepared" (or created using AOP). Note that:
</para>
<itemizedlist>
<listitem>
@@ -44,7 +44,7 @@
<para>You can potentially replace specific class name with wildcard that includes all the POJOs inside the same package space</para>
</listitem>
<listitem>
- <para>The <code>instanceof</code> operator declares any sub-type or sub-class of the specific POJO will also be "aspectized". For example, if a <code>Student</code> class is a subclass of <code>Person</code> , JBossAop will automatically instrument it as well!</para>
+ <para>The <code>instanceof</code> operator declares any sub-type or sub-class of the specific POJO will also be created using AOP. For example, if a <code>Student</code> class is a subclass of <code>Person</code> , JBossAop will automatically instrument it as well!</para>
</listitem>
<listitem>
<para>We intercept the field of all access levels (i.e., <literal>private</literal> , <literal>protected</literal> , <literal>public</literal> , etc.) The main reason being that we consider all fields as stateful data. However, we can relax this requirement in the future if there is a use case for it.</para>
@@ -72,7 +72,7 @@
<prepare expr="field(* $instanceof{@@org.jboss.cache.aop.InstanceOfAopMarker}->*)" />
</aop>
</programlisting>
- Basically, it simply states that any annotation with both marker interfaces will be "aspectized" accordingly.
+ Basically, it simply states that any annotation with both marker interfaces will be coded using AOP accordingly.
</para>
<para>
Here is two code snippets that illustrate the declaration of both types through 1.4 style annotation:
Modified: projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Introduction.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Introduction.xml 2008-08-11 01:59:48 UTC (rev 76872)
+++ projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Introduction.xml 2008-08-11 02:15:59 UTC (rev 76873)
@@ -108,12 +108,12 @@
</listitem>
<listitem>
<para>
- Inheritance relationship. PojoCache preserves the POJO inheritance hierarchy after the object item is stored in the cache. For example, if a <literal>Student</literal> class inherits from a <keycode>Person</keycode> class, once a <literal>Student</literal> object is mapped to PojoCache (e.g., <literal>putObject</literal> call), the attributes in base class <literal>Person</literal> is "aspectized" as well.
+ Inheritance relationship. PojoCache preserves the POJO inheritance hierarchy after the object item is stored in the cache. For example, if a <literal>Student</literal> class inherits from a <keycode>Person</keycode> class, once a <literal>Student</literal> object is mapped to PojoCache (e.g., <literal>putObject</literal> call), the attributes in base class <literal>Person</literal> is coded using Aspect-Oriented Programming (AOP) as well.
</para>
</listitem>
<listitem>
<para>
- Support Collection classes (e.g., List, Set, and Map based objects) automatically without declaring them as aop-enabled. That is, you can use them either as a plain POJO or a sub-object to POJO without declaring them as "aspectized". In addition, it supports runtime swapping of the proxy reference as well.
+ Support Collection classes (e.g., List, Set, and Map based objects) automatically without declaring them as aop-enabled. That is, you can use them either as a plain POJO or a sub-object to POJO without declaring them as coded using AOP. In addition, it supports runtime swapping of the proxy reference as well.
</para>
</listitem>
<listitem>
Modified: projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Term.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Term.xml 2008-08-11 01:59:48 UTC (rev 76872)
+++ projects/docs/enterprise/4.3.3/Cache/Cache_Pojo_Cache_Guide/en-US/Term.xml 2008-08-11 02:15:59 UTC (rev 76873)
@@ -74,7 +74,7 @@
<term>Prepare</term>
<listitem>
<para>
- Prepare is a keyword in JBossAop pointcut language used to specify which POJO needs to be instrumented. It appears in a <literal>jboss-aop.xml</literal> file. However, if you can use annotation to specify the POJO instrumentation, there is no need for a <literal>jboss-aop.xml</literal> listing. Note that When a POJO is declared properly either through the xml or annotation, we consider it "aspectized".
+ Prepare is a keyword in JBossAop pointcut language used to specify which POJO needs to be instrumented. It appears in a <literal>jboss-aop.xml</literal> file. However, if you can use annotation to specify the POJO instrumentation, there is no need for a <literal>jboss-aop.xml</literal> listing.
</para>
</listitem>
</varlistentry>
More information about the jboss-cvs-commits
mailing list