[jboss-cvs] JBossAS SVN: r73606 - projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US.

[jboss-cvs-commits at lists.jboss.org]

Author: skittoli at redhat.com
Date: 2008-05-22 22:00:35 -0400 (Thu, 22 May 2008)
New Revision: 73606

Added:
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/JGroups.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Remoting.xml
Modified:
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/AOP.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Architecture.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Book_Info.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Cache.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Feedback.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Introduction.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Messaging.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Transactions.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Web_Services.xml
   projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/resolved.xml
Log:
added some new files

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/AOP.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/AOP.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/AOP.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -41,12 +41,13 @@
 <formalpara><title>Interceptor</title>
 <para>An interceptor is an Aspect with only one advice named "invoke". It is a specific interface that you can implement if you want your code to be checked by forcing your class to implement an interface. It also will be portable and can be reused in other JBoss environments like EJBs and JMX MBeans. </para>
 </formalpara>
-</section>
 
+<!--merged sections</section>-->
+
 <para>In AOP, a feature like metrics is called a <emphasis>crosscutting concern</emphasis>, as it's a behavior that "cuts" across multiple points in your object models, yet is distinctly different. As a development methodology, AOP recommends that you abstract and encapsulate crosscutting concerns.</para>
 <para>For example, let's say you wanted to add code to an application to measure the amount of time it would take to invoke a particular method. In plain Java, the code would look something like the following. </para>
-<para>
-<programlisting><![CDATA[public class BankAccountDAO
+
+<programlisting role="JAVA">public class BankAccountDAO
 {
  public void withdraw(double amount)
  {
@@ -61,9 +62,10 @@
    System.out.println("withdraw took: " + endTime);
   }
  }
-}]]></programlisting>
-</para>
+}</programlisting>
+
 <para>While this code works, there are a few problems with this approach:
+
 <orderedlist>
 <listitem>
 <para>It's extremely difficult to turn metrics on and off, as you have to manually add the code in the <emphasis>try&gt;/finally</emphasis> block to each and every method or constructor you want to benchmark. </para>
@@ -72,14 +74,20 @@
 <para>The profiling code really doesn't belong sprinkled throughout your application code. It makes your code bloated and harder to read, as you have to enclose the timings within a try/finally block. </para>
 </listitem>
 <listitem>
-<para>If you wanted to expand this functionality to include a method or failure count, or even to register these statistics to a more sophisticated reporting mechanism, you'd have to modify a lot of different files (again). </para>
+<para>If you wanted to expand this functionality to include a method or failure count, or even to register these statistics to a more sophisticated reporting mechanism, you'd have to modify a lot of different files (again).</para>
 </listitem>
 </orderedlist>
 </para>
-<para>This approach to metrics is very difficult to maintain, expand, and extend, because it's dispersed throughout your entire code base. And this is just a tiny example! In many cases, OOP may not always be the best way to add metrics to a class. </para>
 
-<para>Aspect-oriented programming gives you a way to encapsulate this type of behavior functionality. It allows you to add behavior such as metrics "around" your code. For example, AOP provides you with programmatic control to specify that you want calls to BankAccountDAO to go through a metrics aspect before executing the actual body of that code. </para>
+<para>
+	This approach to metrics is very difficult to maintain, expand, and extend, because it's dispersed throughout your entire code base. And this is just a tiny example! In many cases, OOP may not always be the best way to add metrics to a class.
+</para>
 
+<para>
+	Aspect-oriented programming gives you a way to encapsulate this type of behavior functionality. It allows you to add behavior such as metrics "around" your code. For example, AOP provides you with programmatic control to specify that you want calls to BankAccountDAO to go through a metrics aspect before executing the actual body of that code.
+</para>
+</section>
+
 <section>
 	<title>Creating Aspects in JBoss AOP</title>
 	<para>
@@ -90,8 +98,9 @@
 		The first step in creating a metrics aspect in JBoss AOP is to encapsulate the metrics feature in its own Java class. Listing Two extracts the try/finally block in Listing One's BankAccountDAO.withdraw() method into Metrics, an implementation of a JBoss AOP Interceptor class.
 	</para>
 	<para>
-The following listing demonstrates Implementing metrics in a JBoss AOP Interceptor
-<programlisting><![CDATA[01. public class Metrics implements org.jboss.aop.advice.Interceptor
+		The following listing demonstrates Implementing metrics in a JBoss AOP Interceptor
+	</para>
+<programlisting role="JAVA">01. public class Metrics implements org.jboss.aop.advice.Interceptor
 02. {
 03.   public Object invoke(Invocation invocation) throws Throwable
 04.   {
@@ -107,9 +116,8 @@
 14.       System.out.println("method " + m.toString() + " time: " + endTime + "ms");
 15.     }
 16.   }
-17. }]]></programlisting>	
+17. }</programlisting>	
 
-	</para>
 	<para>
 		Under JBoss AOP, the Metrics class wraps withdraw(): when calling code invokes withdraw(), the AOP framework breaks the method call into its parts and encapsulates those parts into an Invocation object. The framework then calls any aspects that sit between the calling code and the actual method body.
 	</para>
@@ -117,29 +125,31 @@
 		When the AOP framework is done dissecting the method call, it calls Metric's invoke method at line 3. Line 8 wraps and delegates to the actual method and uses an enclosing try/finally block to perform the timings. Line 13 obtains contextual information about the method call from the Invocation object, while line 14 displays the method name and the calculated metrics.
 	</para>
 	<para>
-	Having the metrics code within its own object allows us to easily expand and capture additional measurements later on. Now that metrics are encapsulated into an aspect, let's see how to apply it.
+		Having the metrics code within its own object allows us to easily expand and capture additional measurements later on. Now that metrics are encapsulated into an aspect, let's see how to apply it.
 	</para>
 	
 </section>
 	
 <section>
 	<title>Applying Aspects in JBoss AOP</title>
-	<para>To apply an aspect, you define when to execute the aspect code. Those points in execution are called pointcuts. An analogy to a pointcut is a regular expression. Where a regular expression matches strings, a pointcut expression matches events/points within your application. For example, a valid pointcut definition would be "for all calls to the JDBC method executeQuery(), call the aspect that verifies SQL syntax." 
+	<para>
+		To apply an aspect, you define when to execute the aspect code. Those points in execution are called pointcuts. An analogy to a pointcut is a regular expression. Where a regular expression matches strings, a pointcut expression matches events/points within your application. For example, a valid pointcut definition would be "for all calls to the JDBC method executeQuery(), call the aspect that verifies SQL syntax." 
 	</para>
 	<para>
 		An entry point could be a field access, or a method or constructor call. An event could be an exception being thrown. Some AOP implementations use languages akin to queries to specify pointcuts. Others use tags. JBoss AOP uses both. Listing Three shows how to define a pointcut for the metrics example.
 	</para>
 	<para>
-	The following listing demonstrates defining a pointcut in JBoss AOP
-<programlisting><![CDATA[1. <bind pointcut="public void com.mc.BankAccountDAO->withdraw(double amount)">
-2.       <interceptor class="com.mc.Metrics"/>
-3. </bind >
+		The following listing demonstrates defining a pointcut in JBoss AOP
+	</para>
+<programlisting role="XML">1. &lt;bind pointcut="public void com.mc.BankAccountDAO-&gt;withdraw(double amount)"&gt;
+2.       &lt;interceptor class="com.mc.Metrics"/&gt;
+3. &lt;/bind &gt;
 	
-4. <bind pointcut="* com.mc.billing.*->*(..)">
-5.       <interceptor class="com.mc.Metrics"/>
-6. </bind >]]></programlisting>
+4. &lt;bind pointcut="* com.mc.billing.*-&gt;*(..)"&gt;
+5.       &lt;interceptor class="com.mc.Metrics"/&gt;
+6. &lt;/bind &gt;]]&gt;&lt;/programlisting&gt;
+</programlisting>
 
-</para>
 <para>
 	Lines 1-3 define a pointcut that applies the metrics aspect to the specific method BankAccountDAO.withdraw(). Lines 4-6 define a general pointcut that applies the metrics aspect to all methods in all classes in the com.mc.billing package. 
 	There is also an optional annotation mapping if you do not like XML. See our Reference Guide for more information. 
@@ -154,8 +164,7 @@
 	Notice too that the code within the BankAccountDAO class has no idea that it's being profiled. This is what aspect-oriented programmers deem orthogonal concerns. Profiling is an orthogonal concern. In the OOP code snippet in Listing One, profiling was part of the application code. With AOP, you can remove that code. A modern promise of middleware is transparency, and AOP (pardon the pun) clearly delivers. 
 </para>
 <para>
-Just as important, orthogonal behavior could be bolted on after development. In Listing One, monitoring and profiling must be added at development time. With AOP, a developer or an administrator can (easily) add monitoring and metrics as needed without touching the code. This is a very subtle but significant part of AOP, as this separation (obliviousness, some may say) allows aspects to be layered on top of or below the code that they cut across. A layered design allows features to be added or removed at will. For instance, perhaps you snap on metrics only when you're doing some benchmarks, but remove it for production. With AOP, this can be done without editing, recompiling, or repackaging the code. 
+	Just as important, orthogonal behavior could be bolted on after development. In Listing One, monitoring and profiling must be added at development time. With AOP, a developer or an administrator can (easily) add monitoring and metrics as needed without touching the code. This is a very subtle but significant part of AOP, as this separation (obliviousness, some may say) allows aspects to be layered on top of or below the code that they cut across. A layered design allows features to be added or removed at will. For instance, perhaps you snap on metrics only when you're doing some benchmarks, but remove it for production. With AOP, this can be done without editing, recompiling, or repackaging the code. 
 </para>
 </section>
-</chapter>
-
+</chapter>
\ No newline at end of file

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -2,7 +2,7 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
 ]>
 
-<book>
+<book><!--<title>JBoss AS 5 Administration and Configuration Guide</title>-->
 	<xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="What_This_Book_Covers.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	
@@ -31,6 +31,8 @@
 		<xi:include href="AOP.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 		<xi:include href="Cache.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 		<xi:include href="Transactions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+		<xi:include href="JGroups.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+		<xi:include href="Remoting.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 		<xi:include href="Messaging.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 		
 	</part>

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Alternative_DBs.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -5,7 +5,7 @@
     <para>JBoss utilizes the Hypersonic database as its default database. While this is good for development and prototyping, you or your company will probably require another database to be used for production. This chapter covers configuring JBoss AS to use alternative databases. We cover the procedures for all officially supported databases on the JBoss Application Server. They include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, Sybase ASE 12.5, as well as MS SQL 2005.
     </para>
 		
-    <para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss AS. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss AS, you can still use any backend database by setting up the appropriate data source connection as described in <xref linkend="Connectors_on_JBoss-Configuring_JDBC_DataSources"/>.</para>
+    <para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss AS. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss AS, you can still use any backend database by setting up the appropriate data source connection. </para>
         
     <para>We assume that you have already installed the external database server, and have it running. You should create an empty database named <literal>jboss</literal>, accessible via the username / password pair <literal>jbossuser / jbosspass</literal>. The <literal>jboss</literal> database is used to store JBoss AS internal data -- JBoss AS will automatically create tables and data in it.</para>
 		

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Architecture.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Architecture.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Architecture.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -4,14 +4,15 @@
 
 <chapter id="JBoss_AS5_Architecture">
 	<title>JBoss Application Server 5 architecture</title>
+	<para>
 	The following diagram illustrates an overview of the JBoss.org community projects including the JBoss Appplication Server and its components.
 	<inlinemediaobject>
 		<imageobject>
 			<imagedata fileref="images/projects_communitygraph.png"/>
 		</imageobject>
 	</inlinemediaobject>
+</para>
 	
-	
 	<para>
 		The directory structure of JBoss 5 resembles that of the 4.x series with some notable differences:
 <screen><![CDATA[-&lt;JBOSS_HOME&gt;/ - the path to your JBoss AS installation.

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Book_Info.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Book_Info.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Book_Info.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -10,7 +10,7 @@
 	<pubdate>Mar 2008</pubdate>
 	<abstract>
 		<para>
-			This book is a guide to the administration and configuration of the JBoss Application Server 5.0.0.
+			This book is a <literal>"Work In Progress"</literal> guide to the administration and configuration of the JBoss Application Server 5.
 		</para>
 	</abstract>
 	<subtitle>Authors</subtitle>

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Cache.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Cache.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Cache.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -24,6 +24,7 @@
 		</listitem>
 	</orderedlist>
 	<para>Pojo Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial and as such, Pojo Cache is not discussed further in this book. </para>
+	<para>Pojo Cache deployment in the JBoss AS5 is discussed more in <xref linkend="pojocachedeployment"/></para>	
 </section>
 <section><title>Summary of Features</title>
 	<para>JBoss Cache offers a simple and straightforward API, where data (simple Java objects) can be placed in the cache and, based on configuration options selected, this data may be one or all of: </para>
@@ -57,65 +58,16 @@
 	<para>JBoss Cache works out of the box with most popular transaction managers, and even provides an API where custom transaction manager lookups can be written. </para>
 	<para>The cache is also completely thread-safe. It uses a pessimistic locking scheme for nodes in the tree by default, with an optimistic locking scheme as a configurable option. With pessimistic locking, the degree of concurrency can be tuned using a number of isolation levels, corresponding to database-style transaction isolation levels, i.e., SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED and NONE. Concurrency, locking and isolation levels will be discussed later. </para>
 </section>
-<section>
-	<title>JGroups </title>
-	<para>JGroups is a toolkit for reliable multicast communication. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.</para>
-	<para/>
-	<orderedlist>
-		<listitem>
-			<para>Group creation and deletion. Group members can be spread across LANs or WANs </para>
-		</listitem>
-		<listitem>
-			<para>Joining and leaving of groups </para>
-		</listitem>
-		<listitem>
-			<para>Membership detection and notification about joined/left/crashed members </para>
-		</listitem>
-		<listitem>
-			<para>Detection and removal of crashed members </para>
-		</listitem>
-		<listitem>
-			<para>Sending and receiving of member-to-group messages (point-to-multipoint) </para>
-		</listitem>
-		<listitem>
-			<para>Sending and receiving of member-to-member messages (point-to-point) </para>
-		</listitem>
-	</orderedlist>
-</section>
-	<section>
-		<title>Flexible Protocol Stack</title>
-	<para>The most powerful feature of JGroups is its flexible protocol stack, which allows developers to adapt it to exactly match their application requirements and network characteristics. The benefit of this is that you only pay for what you use. By mixing and matching protocols, various differing application requirements can be satisfied. JGroups comes with a number of protocols (but anyone can write their own), for example </para>
-	<para>
-	<orderedlist>
-		<listitem>
-			<para>Transport protocols: UDP (IP Multicast), TCP, JMS </para>
-		</listitem>
-		<listitem>
-			<para>Fragmentation of large messages </para>
-		</listitem>
-		<listitem>
-			<para>Reliable unicast and multicast message transmission. Lost messages are retransmitted </para>
-		</listitem>
-		<listitem>
-			<para>Failure detection: crashed members are excluded from the membership </para>
-		</listitem>
-		<listitem>
-			<para>Ordering protocols: Atomic (all-or-none message delivery), Fifo, Causal, Total Order (sequencer or token based) </para>
-		</listitem>
-		<listitem>
-			<para>Membership </para>
-		</listitem>
-		<listitem>
-			<para>Encryption </para>
-		</listitem>
-	</orderedlist>
-</para>
-</section>
 
+
 <section>
 	<title>Running JBoss Cache in the JBoss Application server</title>
-	<para>The following is the JBoss Cache JGroups and JBoss Application Server compatibility matrix.</para>
 	<para>
+		JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found on <xref linkend="jgroups"/>
+	</para>
+	
+	<!--<para>The following is the JBoss Cache JGroups and JBoss Application Server compatibility matrix.</para>
+	<para>
 		<table frame="all"><title>JBoss Application Server + JBoss Cache</title>
 		<tgroup cols="3"><tbody>
 				<row>
@@ -244,10 +196,11 @@
 	</table>
 <note><title></title><para>For JBoss AS 4.0.3SP1 (and earlier) to run with JBoss Cache 1.4.0.x you need to add jboss-serialization.jar to JBOSS_HOME/server/all/lib </para></note>
 
-<note><title></title><para>Upgrading to these JBoss Cache versions within JBoss AS 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>
+<note><title></title><para>Upgrading to these JBoss Cache versions within JBoss AS 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>-->
 	
 
 <para>	
+	<!--
 	<table frame="all"><title>JBoss Application Server + Jgroups compatibility matrix</title>
 		<tgroup cols="3"><tbody>
 				<row>
@@ -462,11 +415,11 @@
 						<para/>
 					</entry>
 				</row></tbody></tgroup>
-	</table>
+	</table>-->
 </para>
 
-	
-	<table frame="all"><title>JBoss Cache + Jgroups compatibility matrix</title>
+<para>	
+	<!--<table frame="all"><title>JBoss Cache + Jgroups compatibility matrix</title>
 		<tgroup cols="3"><tbody>
 				<row>
 					<entry>
@@ -623,7 +576,7 @@
 						<para/>
 					</entry>
 				</row></tbody></tgroup>
-	</table>
+	</table>-->
 </para>
 
 	<para>In the JBoss Application Server 5, JBoss cache runs in the <emphasis>all</emphasis> configuration of the application server(i.e &lt;JBOSS_HOME&gt;/server/all). All you need to do is start the server with this configuration.
@@ -652,6 +605,104 @@
 	<para>Once the proxy to the CacheJmxWrapper is obtained, the getCache() will return a reference to the Cache itself. </para>
 </section>
 
+<section id="pojocachedeployment"><title>Pojo Cache Deployment Options</title>
+	<para>
+		There are a number of ways to deploy POJO Cache:
+	</para>
+	<section><title>Programatic Deployment</title>
+		<para>
+		Simply instantiate a PojoCacheFactory and invoke one of the overloaded createCache methods shown in the API Overview.
+		</para>
+	</section>
+	<section><title>JMX-Based Deployment in JBoss AS (JBoss AS 5.x and 4.x)</title>
+		<para>
+		If PojoCache is run in JBoss AS then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss AS MBean deployment descriptor, so the AS's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
+		</para>
+		<para>
+		In AS 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR.
+		</para>
+		<para>
+		It is possible, to deploy a POJO Cache 2.0 instance in JBoss AS 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in AS 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
+		</para>
+		<para>
+		Note in the example the value of the mbean element's code attribute: org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper. This is the class JBoss Cache uses to handle JMX integration; the PojoCache itself does not expose an MBean interface. See the JBoss Cache MBeans section for more on the PojoCacheJmxWrapper.
+		</para>
+		<para>
+		Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache:
+		</para>
+<programlisting role="JAVA">MBeanServer server = MBeanServerLocator.locateJBoss();
+		
+	ObjectName on = new ObjectName("jboss.cache:service=PojoCache");
+	
+	PojoCacheJmxWrapperMBean cacheWrapper =
+	
+	(PojoCacheJmxWrapperMBean) MBeanServerInvocationHandler.newProxyInstance(server, on,
+		
+	PojoCacheJmxWrapperMBean.class, false);
+		
+	PojoCache cache = cacheWrapper.getPojoCache();</programlisting>		
+		
+	<para>	
+		The MBeanServerLocator class is a helper to find the (only) JBoss MBean server inside the current JVM. The javax.management.MBeanServerInvocationHandler class' newProxyInstance method creates a dynamic proxy implementing the given interface and uses JMX to dynamically dispatch methods invoked against the generated interface to the MBean. The name used to look up the MBean is the same as defined in the cache's configuration file.
+	</para>
+	<para>
+		Once the proxy to the PojoCacheJmxWrapper is obtained, the getPojoCache() will return a reference to the PojoCache itself.
+	</para>
+</section>
+<section><title>Via JBoss Microcontainer (JBoss AS 5.x)</title>
+		<para>
+		Beginning with AS 5, JBoss AS also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.
+	</para>
+	<para>
+		Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss AS. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service.
+	</para>
+	<para>
+		The rules for how to deploy the file, how to package it, how to ensure the required jars are on the classpath, etc. are the same as for a JMX-based deployment.
+	</para>
+	<para>
+		Following is an abbreviated example -beans.xml file. The details of building up the Configuration are omitted; see the "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for a more complete example. If you look in the <filename>server/all/deploy</filename> directory of an AS 5 installation, you can find several more examples.
+	</para>
+		
+	<programlisting role="XML">&lt;?xml version="1.0" encoding="UTF-8"?&gt;
+&lt;deployment xmlns="urn:jboss:bean-deployer:2.0"&gt;
+		
+	&lt;!-- First we create a Configuration object for the cache --&gt;
+		
+	&lt;bean name="ExampleCacheConfig"
+	
+	class="org.jboss.cache.config.Configuration"&gt;
+		
+	... details omitted
+		
+		
+	&lt;/bean&gt;
+		
+&lt;!-- The cache itself. --&gt;
+		
+&lt;bean name="ExampleCache" class="org.jboss.cache.pojo.impl.PojoCacheImpl"&gt;
+		
+	&lt;constructor factoryClass="org.jboss.cache.pojo.PojoCacheFactory
+		
+		factoryMethod="createCache"&gt;
+		
+	&lt;parameter&gt;&lt;inject bean="ExampleCacheConfig"/&gt;&lt;/parameter&gt;
+		
+	&lt;parameter&gt;false&lt;/false&gt;
+		
+	&lt;/constructor&gt;
+		
+&lt;/bean&gt;
+		
+&lt;/deployment&gt;....</programlisting>			
+	
+	<para>
+		An interesting thing to note in the above example is the difference between POJO Cache and a plain Cache in the use of a factory to create the cache. (See the "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for the comparable plain Cache example.) The PojoCacheFactory exposes static methods for creating a PojoCache; as a result there is no need to add a separate bean element for the factory. Core Cache's DefaultCacheFactory creates caches from a singleton instance, requiring a bit more boilerplate in the config file.
+	</para>
+	</section>
+</section>	
+
+
+
 <section><title>References:</title>
 	<para>
 		More information on JBoss Cache can be obtained from the following resources:

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Feedback.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Feedback.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Feedback.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -15,11 +15,12 @@
 	<note><title>Note</title><para>This content is taken from svn.jboss.org/repos/jbossas/projects/docs/trunk and has yet to be branched.</para></note>
 	
 	<para>To access the content directly and make changes yourself:</para>
-	<screen>
-		svn co https://svn.jboss.org/repos/jbossas/projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/ --username yourname
+<screen>svn co https://svn.jboss.org/repos/jbossas/projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/ --username yourname
 	</screen>
 	
 	<para>The directory structure includes other languages the book will be translated in. For English please edit the files under <emphasis>en-US</emphasis>.
 	</para>
+	<para>To identify the filename you wish to edit, please check the chapter title which will match the file's name. The files are written in Docbook xml. After saving your changes please validate the files you've edited for error's before committing your changes.
+	</para>
 	
 </section>
\ No newline at end of file

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Introduction.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Introduction.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Introduction.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -9,6 +9,9 @@
 		The JBoss Microcontainer is a lightweight container that supports direct deployment, configuration and lifecycle of plain old Java objects (POJOs).
 		The JBoss Microcontainer project is standalone and replaces the JBoss JMX Microkernel used in the 3.x and 4.x JBoss Application Servers.
 		Project goals include:
+	</para>
+	
+	<para>
 	<itemizedlist>
 		<listitem>
 			<para>
@@ -36,7 +39,7 @@
 			</para>
 		</listitem>
 	</itemizedlist>
-		 
+	 
 		The JBoss Microcontainer integrates nicely with the JBoss Aspect
 		Oriented Programming framework (JBoss AOP). JBoss AOP is discussed in <xref linkend="jboss_aop"/> Support for JMX in JBoss AS 5 remains strong and MBean services written against the old Microkernel are expected to work.
 	</para>
@@ -49,6 +52,7 @@
 	
 	<para>
 		A sample Java EE 5 application that can be run on top of JBoss 5.0.0.Beta4 and above which demonstrates many interesting technologies is the Seam Booking Application available on <ulink url="http://seam.demo.jboss.com/home.seam"/>. This application makes use of the following technologies running on JBoss AS5:
+		
 	<itemizedlist>
 		<listitem>
 			<para>EJB3
@@ -91,48 +95,47 @@
 		</listitem>
 	</itemizedlist>
 		
-
 	</para>
 	
 	<para>
 		Many key features of JBoss AS5 are provided by integrating other standalone JBoss projects which include: -
 	<itemizedlist>
-		<listitem>
-			<para>
-		JBoss EJB3 included with JBoss 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss AS 4.x series.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBossCache 2.0 that comes in two flavors. A traditional tree-structured node-based cache and a PojoCache, an in-memory, transactional, and replicated cache system that allows users to operate on simple POJOs transparently without active user management of either replication or persistency aspects.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBossWS 2 is the web services stack for JBoss 5 providing Java EE compatible web services, JAXWS-2.0.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBoss Transactions is the default transaction manager for JBoss 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBoss Web is the Web container in JBoss 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
-			</para>
-		</listitem>
-	</itemizedlist>
+	<listitem>
+		<para>
+			JBoss EJB3 included with JBoss 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss AS 4.x series.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBossCache 2.0 that comes in two flavors. A traditional tree-structured node-based cache and a PojoCache, an in-memory, transactional, and replicated cache system that allows users to operate on simple POJOs transparently without active user management of either replication or persistency aspects.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBossWS 2 is the web services stack for JBoss 5 providing Java EE compatible web services, JAXWS-2.0.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBoss Transactions is the default transaction manager for JBoss 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBoss Web is the Web container in JBoss 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
+		</para>
+	</listitem>
+</itemizedlist>
 	
 	JBoss AS5 includes numerous features and bug fixes, many of them carried over upstream from the JBoss AS4.x codebase. See the Detailed Release Notes section for the full details.
-	</para>
+</para>
 	
-	<section><title>JBoss Application Server use cases</title>
+<section><title>JBoss Application Server use cases</title>
 		<para>
 			<itemizedlist>
 				<listitem>
@@ -226,15 +229,35 @@
 	</itemizedlist>
 	</para>
 	
-	</section>
-		
+	
 	<para>
-		More information about JBoss Enterprise Application Platform and Enterprise middleware can be obtained on <ulink url="http://www.jboss.com/products/index"/> and <ulink url="http://www.redhat.com/promo/migration/"/>. 
+		More information about JBoss Enterprise Application Platform and Enterprise middleware can be obtained on <ulink url="http://www.jboss.com/products/index"/> and <ulink url="http://www.redhat.com/promo/migration/"/>
 	</para>
 	
 	</section>
+		
 	
+	
+</section>
+	
 		
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 	<section>
 		<title>JBoss Application Server 5 compatibility issues</title>
 		<para>
@@ -296,5 +319,6 @@
 	
 	</para>
 </section>
+
 </chapter>
 

Added: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/JGroups.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/JGroups.xml	                        (rev 0)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/JGroups.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -0,0 +1,71 @@
+<?xml version='1.0'?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+	  ]>
+
+<chapter id="jgroups"><title>JGroups</title>
+	
+	<para>
+		JBoss AS clustering is built on JGroups - a toolkit for reliable multicast communication between AS server nodes on an existing computer network. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
+	</para>
+
+	
+	<orderedlist>
+		<listitem>
+			<para>Group creation and deletion. Group members can be spread across LANs or WANs </para>
+		</listitem>
+		<listitem>
+			<para>Joining and leaving of groups </para>
+		</listitem>
+		<listitem>
+			<para>Membership detection and notification about joined/left/crashed members </para>
+		</listitem>
+		<listitem>
+			<para>Detection and removal of crashed members </para>
+		</listitem>
+		<listitem>
+			<para>Sending and receiving of member-to-group messages (point-to-multipoint) </para>
+		</listitem>
+		<listitem>
+			<para>Sending and receiving of member-to-member messages (point-to-point) </para>
+		</listitem>
+	</orderedlist>
+
+
+	<section>
+		<title>Flexible Protocol Stack</title>
+	<para>
+		The most powerful feature of JGroups is its flexible protocol stack, which allows developers to adapt it to exactly match their application requirements and network characteristics. The benefit of this is that you only pay for what you use. By mixing and matching protocols, various differing application requirements can be satisfied. JGroups comes with a number of protocols (but anyone can write their own), for example.
+	</para>
+	<para>
+	<orderedlist>
+		<listitem>
+			<para>Transport protocols: UDP (IP Multicast), TCP, JMS </para>
+		</listitem>
+		<listitem>
+			<para>Fragmentation of large messages </para>
+		</listitem>
+		<listitem>
+			<para>Reliable unicast and multicast message transmission. Lost messages are retransmitted </para>
+		</listitem>
+		<listitem>
+			<para>Failure detection: crashed members are excluded from the membership </para>
+		</listitem>
+		<listitem>
+			<para>Ordering protocols: Atomic (all-or-none message delivery), Fifo, Causal, Total Order (sequencer or token based) </para>
+		</listitem>
+		<listitem>
+			<para>Membership </para>
+		</listitem>
+		<listitem>
+			<para>Encryption </para>
+		</listitem>
+	</orderedlist>
+</para>
+
+    <para>
+	    More information on JGroups can be found on the <ulink url="http://www.jboss.org/jgroups/">The JGroups homepage</ulink>
+    </para>
+
+</section>
+
+</chapter>
\ No newline at end of file

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Messaging.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Messaging.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Messaging.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -39,8 +39,444 @@
 <para>JBoss Messaging is destined to become an integral part of the JBoss Enterprise Application Platform, and the new Service Integration Platform.</para>
 <para>JBoss Messaging is also an integral part of Red Hat's strategy for messaging. JBoss Messaging is committed to AMQP ( <ulink url="http://www.amqp.org/">AMQP</ulink>)- the new messaging standard from Red Hat and others. Later versions of JBoss Messaging will support AMQP, and JBoss Messaging will be focussed on becoming the premier AMQP Java broker.</para>
 
+<section><title>Configuring JBoss Messaging</title>
+	
 <para>
- ....... more content coming..conversion of doc in progress
+	The JBoss Messaging service configuration is spread among several configuration files. Depending on the functionality provided by the services it configures, the configuration data is distributed between <filename>&lt;JBOSS_HOME&gt;/server/&lt;configuration&gt;/deploy/messaging-service.xml, remoting-service.xml, connection-factories-service.xml, destinations-service.xml and  xxx-persistence-service.xml</filename> (where <literal>xxx</literal> is the name of your database). The default will be <filename>hsqldb-persistence-service.xml</filename> for the hsqldb database.	
 </para>
 
+<section><title>Configuring the SecurityStore</title>
+<para>
+	SecurityStore is a pluggable object, and it has a default implementation on <filename>messaging-service.xml</filename>.
+</para>
+<programlisting role="XML">&lt;server&gt;
+	&lt;mbean code="org.jboss.jms.server.security.SecurityMetadataStore"
+	name="jboss.messaging:service=SecurityStore"&gt;
+	
+	&lt;attribute name="DefaultSecurityConfig"&gt;
+	&lt;security&gt;
+	&lt;role name="guest" read="true" write="true" create="true"/&gt;
+	&lt;/security&gt;
+	&lt;/attribute&gt;
+	
+	&lt;attribute name="SecurityDomain"&gt;java:/jaas/messaging&lt;/attribute&gt;
+	
+	&lt;attribute name="SuckerPassword"&gt;CHANGE ME!!&lt;/attribute&gt;
+&lt;/mbean&gt;
+...
+...file truncated..
+</programlisting>
+</section>
+
+<section><title>SecurityStore Attributes</title>
+<para>The following are SecurityStore attributes from the <filename>messaging-service.xml</filename> file above.
+</para>
+
+<section><title>DefaultSecurityConfig</title>
+	<para>
+		Default security configuration is used when the security configuration for a specific queue or topic has not been overridden in the destination's deployment descriptor. It has exactly the same syntax and semantics as in JBossMQ.
+	</para>
+	<para>
+	The DefaultSecurityConfig attribute element should contain one &lt;security&gt; element. The &lt;security&gt; element can contain multiple &lt;role&gt; elements. Each &lt;role&gt; element defines the default access for that particular role.
+	</para>
+	<para>
+	If the read attribute is true then that role will be able to read (create consumers, receive messaages or browse) destinations by default.
+						
+	If the write attribute is true then that role will be able to write (create producers or send messages) to destinations by default. If the create attribute is true then that role will be able to create durable subscriptions on topics by default.
+	</para>
+</section>
+
+<section><title>SecurityDomain</title>
+	<para>
+		The JAAS security domain to be used by this server peer.
+	</para>
+</section>
+
+<section><title>SuckerPassword</title>
+	<para>
+		This defines how the SecurityStore will authenticate the sucker user (<literal>JBM.SUCKER</literal>).
+	</para>
+</section>
+
+
+
+</section>
+
+</section>
+
+<section><title>Configuring the ServerPeer</title>
+<para>
+	The Server Peer is the heart of the JBoss Messaging JMS facade. The server's configuration, resides in <filename>messaging-service.xml</filename> configuration file.
+	
+	All JBoss Messaging services are rooted at the server peer.
+	
+	An example of a Server Peer configuration is presented below. Note that not all values for the server peer's attributes are specified in the example.
+</para>
+
+<programlisting role="XML">&lt;!-- ServerPeer MBean configuration
+	============================== --&gt;
+	
+	&lt;mbean code="org.jboss.jms.server.ServerPeer"
+	name="jboss.messaging:service=ServerPeer"
+	xmbean-dd="xmdesc/ServerPeer-xmbean.xml"&gt;
+	
+	&lt;!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer --&gt;
+	
+	&lt;attribute name="ServerPeerID"&gt;${jboss.messaging.ServerPeerID:0}&lt;/attribute&gt;
+	
+	&lt;!-- The default JNDI context to use for queues when they are deployed without specifying one --&gt; 
+	
+	&lt;attribute name="DefaultQueueJNDIContext"&gt;/queue&lt;/attribute&gt;
+	
+	&lt;!-- The default JNDI context to use for topics when they are deployed without specifying one --&gt; 
+	
+	&lt;attribute name="DefaultTopicJNDIContext"&gt;/topic&lt;/attribute&gt;
+	
+	&lt;attribute name="PostOffice"&gt;jboss.messaging:service=PostOffice&lt;/attribute&gt;
+	
+	&lt;!-- The default Dead Letter Queue (DLQ) to use for destinations.
+	This can be overridden on a per destinatin basis --&gt;
+	
+	&lt;attribute name="DefaultDLQ"&gt;jboss.messaging.destination:service=Queue,name=DLQ&lt;/attribute&gt;
+	
+	&lt;!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).
+	This can be overridden on a per destinatin basis --&gt;
+	
+	&lt;attribute name="DefaultMaxDeliveryAttempts"&gt;10&lt;/attribute&gt;
+	
+	&lt;!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis --&gt;
+	
+	&lt;attribute name="DefaultExpiryQueue"&gt;jboss.messaging.destination:service=Queue,name=ExpiryQueue&lt;/attribute&gt;
+	
+	&lt;!-- The default redelivery delay to impose. This can be overridden on a per destination basis --&gt;
+	
+	&lt;attribute name="DefaultRedeliveryDelay"&gt;0&lt;/attribute&gt;
+	
+	&lt;!-- The periodicity of the message counter manager enquiring on queues for statistics --&gt;
+	
+	&lt;attribute name="MessageCounterSamplePeriod"&gt;5000&lt;/attribute&gt;
+	
+	&lt;!-- The maximum amount of time for a client to wait for failover to start on the server side after
+	it has detected failure --&gt;
+	
+	&lt;attribute name="FailoverStartTimeout"&gt;60000&lt;/attribute&gt;
+	
+	&lt;!-- The maximum amount of time for a client to wait for failover to complete on the server side after
+	it has detected failure --&gt;
+	
+	&lt;attribute name="FailoverCompleteTimeout"&gt;300000&lt;/attribute&gt;
+	
+	&lt;attribute name="StrictTck"&gt;false&lt;/attribute&gt;
+	
+	&lt;!-- The maximum number of days results to maintain in the message counter history --&gt;
+	
+	&lt;attribute name="DefaultMessageCounterHistoryDayLimit"&gt;-1&lt;/attribute&gt;
+	
+	&lt;!-- The name of the connection factory to use for creating connections between nodes to pull messages --&gt;
+	
+	&lt;attribute name="ClusterPullConnectionFactoryName"&gt;jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory&lt;/attribute&gt;
+	
+	&lt;!-- When redistributing messages in the cluster. Do we need to preserve the order of messages received
+	by a particular consumer from a particular producer? --&gt;
+	
+	&lt;attribute name="DefaultPreserveOrdering"&gt;false&lt;/attribute&gt;
+	
+	&lt;!-- Max. time to hold previously delivered messages back waiting for clients to reconnect after failover --&gt;
+	
+	&lt;attribute name="RecoverDeliveriesTimeout"&gt;300000&lt;/attribute&gt;
+	
+	&lt;!-- The password used by the message sucker connections to create connections.
+	THIS SHOULD ALWAYS BE CHANGED AT INSTALL TIME TO SECURE SYSTEM
+	&lt;attribute name="SuckerPassword"&gt;&lt;/attribute&gt;
+	--&gt;
+	
+	&lt;!-- The name of the server aspects configuration resource
+	&lt;attribute name="ServerAopConfig"&gt;aop/jboss-aop-messaging-server.xml&lt;/attribute&gt;
+	--&gt;
+	&lt;!-- The name of the client aspects configuration resource
+	&lt;attribute name="ClientAopConfig"&gt;aop/jboss-aop-messaging-client.xml&lt;/attribute&gt;
+	--&gt;
+	
+	&lt;depends optional-attribute-name="PersistenceManager"&gt;jboss.messaging:service=PersistenceManager&lt;/depends&gt;
+	
+	&lt;depends optional-attribute-name="JMSUserManager"&gt;jboss.messaging:service=JMSUserManager&lt;/depends&gt;
+	
+	&lt;depends&gt;jboss.messaging:service=Connector,transport=bisocket&lt;/depends&gt;
+	&lt;depends optional-attribute-name="SecurityStore"
+	proxy-type="org.jboss.jms.server.SecurityStore"&gt;jboss.messaging:service=SecurityStore&lt;/depends&gt;
+&lt;/mbean&gt;
+...
+</programlisting>
+
+</section>
+
+<section><title>Server Attributes</title>
+<para>
+	This section discusses the MBean attributes of the ServerPeer MBean.
+</para>
+
+<section><title>ServerPeerID</title>
+<para>
+The unique id of the server peer. Every node you deploy MUST have a unique id. This applies whether the different nodes form a cluster, or are only linked via a message bridge. The id must be a valid integer.
+</para>
+</section>
+
+<section><title>DefaultQueueJNDIContext</title>
+	<para>
+	The default JNDI context to use when binding queues. Defaults to <literal>/queue</literal>.
+	</para>
+</section>
+<section><title>DefaultTopicJNDIContext</title>
+	<para>
+	The default JNDI context to use when binding topics.wa Defaults to <literal>/topic</literal>.
+	</para>
+</section>
+<section><title>PostOffice</title>
+	<para>
+	This is the post office that the ServerPeer uses. You will not normally need to change this attribute. The post office is responsible for routing messages to queues and maintaining the mapping between addresses and queues.
+	</para>
+</section>
+<section><title>DefaultDLQ</title>
+	<para>
+	This is the name of the default DLQ (Dead Letter Queue) the server peer will use for destinations. The DLQ can be overridden on a per destination basis - see the destination MBean configuration for more details. A DLQ is a special destination where messages are sent when the server has attempted to deliver them unsuccessfully more than a certain number of times. If the DLQ is not specified at all then the message will be removed after the maximum number of delivery attempts. The maximum number of delivery attempts can be specified using the attribute DefaultMaxDeliveryAttempts for a global default or individually on a per destination basis.
+	</para>
+</section>
+<section><title>DefaultMaxDeliveryAttempts</title>
+	<para>
+	The default for the maximum number of times delivery of a message will be attempted before sending the message to the DLQ, if configured.
+	</para>
+	<para>The default value is 10.This value can also be overridden on a per destination basis.
+	</para>
+</section>
+<section><title>DefaultExpiryQueue</title>
+	<para>
+		This is the name of the default expiry queue the server peer will use for destinations. The expiry can be overridden on a per destination basis - see the destination MBean configuration for more details. An expiry queue is a special destination where messages are sent when they have expired. Message expiry is determined by the value of Message::getJMSExpiration() If the expiry queue is not specified at all then the message will be removed after it is expired.
+	</para>
+</section>
+<section><title>DefaultRedeliveryDelay</title>
+	<para>
+		When redelivering a message after failure of previous delivery it is often beneficial to introduce a delay perform redelivery in order to prevent thrashing of delivery-failure, delivery-failure etc.
+	</para>
+	<para>
+	The default value is 0 which means there will be no delay.
+	</para>
+	<para>
+	Change this if your application could benefit with a delay before redelivery. This value can also be overridden on a per destination basis.
+	</para>
+</section>
+<section><title>MessageCounterSamplePeriod</title>
+	<para>
+		Periodically the server will query each queue to gets its statistics. This is the period.
+	</para>
+	<para>
+		The default value is 10000 milliseconds.
+	</para>
+</section>
+<section><title>FailoverStartTimeout</title>
+	<para>
+		The maximum number of milliseconds the client will wait for failover to start on the server side when a problem is detected.
+	</para>
+	<para>
+		The default value is 60000 (one minute).
+	</para>
+</section>
+<section><title>FailoverCompleteTimeout</title>
+	<para>
+		The maximum number of milliseconds the client will wait for failover to complete on the server side after it has started. The default value is 300000 (five minutes).
+	</para>
+</section>
+<section><title>DefaultMessageCounterHistoryDayLimit</title>
+	<para>
+		JBoss Messaging provides a message counter history which shows the number of messages arriving on each queue of a certain number of days. This attribute represents the maxiumum number of days for which to store message counter history. It can be overridden on a per destination basis.
+	</para>
+</section>
+<section><title>ClusterPullConnectionFactory</title>
+	<para>
+		The name of the connection factory to use for pulling messages between nodes.
+		If you wish to turn off message sucking between queues altogether, but retain failover, then you can ommit this attribute altogether.
+	</para>
+</section>
+<section><title>DefaultPreserveOrdering</title>
+	<para>
+		If true, then strict JMS ordering is preserved in the cluster. See the cluster configurations section for more details. Default is false.
+	</para>
+</section>
+<section><title>RecoverDeliveriesTimeout</title>
+	<para>
+		When failover occurs, already delivered messages will be kept aside, waiting for clients to reconnect. In the case that clients never reconnect (e.g. the client is dead) then eventually these messages will timeout and be added back to the queue. The value is in ms. The default is 5 mins.
+	</para>
+</section>
+<section><title>SuckerPassword</title>
+		<para>
+		JBoss Messaging internally makes connections between nodes in order to redistribute messages between clustered destinations. These connections are made with the user name of a special reserved user. On this parameter you define the password used as these connections are made. After JBossMessaging 1.4.1.GA you will need to define the Sucker Password on the ServerPeer and on the SecurityMetadataStore.
+	</para>
+<warning><title>Warning</title>
+<para>This must be specified at install time, or the default password will be used. Any one who then knows the default password will be able to gain access to any destinations on the server. This value MUST be changed at install time.</para>
+</warning>
+</section>
+<section><title>StrictTCK</title>
+	<para>Set to true if you want strict JMS TCK semantiocs
+	</para>
+</section>
+<section><title>Destinations</title>
+	<para>
+		Returns a list of the destinations (queues and topics) currently deployed.
+	</para>
+</section>
+<section><title>MessageCounters</title>
+	<para>
+		JBoss Messaging provides a message counter for each queue.
+	</para>
+</section>
+<section><title>MessageCountersStatistics</title>
+	<para>
+		JBoss Messaging provides statistics for each message counter for each queue.
+	</para>
+</section>
+<section><title>SupportsFailover</title>
+<para>
+	Set to false to prevent server side failover occurring in a cluster when a node crashes.
+</para>
+</section>
+<section><title>PersistenceManager</title>
+	<para>
+		This is the persistence manager that the ServerPeer uses. You will not normally need to change this attribute.
+	</para>
+</section>
+<section><title>JMSUserManager</title>
+	<para>
+		This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
+	</para>
+</section>
+<section><title>SecurityStore</title>
+	<para>
+		This is the pluggable SecurityStore. If you redefine this SecurityStore, notice it will need to authenticate the MessageSucker user ("JBM.SUCKER") with all the special permissions required by clustering.
+	</para>
+</section>
+
+</section>
+
+<section><title>MBean operations of the ServerPeer MBean</title>
+	<para>
+	</para>
+
+<section><title>DeployQueue</title>
+	<para>
+		This operation lets you programmatically deploy a queue. There are two overloaded versions of this operation. If the queue already exists but is undeployed it is deployed. Otherwise it is created and deployed. The <literal>name</literal> parameter represents the name of the destination to deploy. The <literal>jndiName</literal> parameter (optional) represents the full jndi name where to bind the destination. If this is not specified then the destination will be bound in <literal>&lt;DefaultQueueJNDIContext&gt;/&lt;name&gt;</literal>.
+	</para>
+	<para>
+		The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the paging parameters mean.
+	</para>
+</section>
+<section><title>UndeployQueue</title>
+	<para>
+		This operation lets you programmatically undeploy a queue.
+		The queue is undeployed but is NOT removed from persistent storage.
+		This operation returns true if the queue was successfull undeployed. otherwise it returns false.
+	</para>
+</section>
+<section><title>DestroyQueue</title>
+	<para>
+		This operation lets you programmatically destroy a queue.
+		The queue is undeployed and then all its data is destroyed from the database.
+	
+	
+<warning><title>Warning</title>
+<para>Be cautious when using this method since it will delete all data for the queue.</para>
+</warning>
+	
+		This operation returns true if the queue was successfully destroyed. otherwise it returns false.
+	</para>
+
+</section>
+<section><title>DeployTopic</title>
+	<para>
+		This operation lets you programmatically deploy a topic.
+	</para>
+	<para>
+		There are two overloaded versions of this operation.
+	</para>	
+	<para>
+		If the topic already exists but is undeployed it is deployed. Otherwise it is created and deployed.
+	</para>
+	<para>
+		The name parameter represents the name of the destination to deploy.
+	</para>
+	<para>
+		The jndiName parameter (optional) represents the full jndi name where to bind the destination. If this is not specified then the destination will be bound in &lt;DefaultTopicJNDIContext&gt;/&lt;name&gt;.
+	</para>
+	<para>
+		The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the paging parameters mean.
+	</para>
+
+</section>
+<section><title>UndeployTopic</title>
+	<para>
+		This operation lets you programmatically undeploy a topic.
+		The queue is undeployed but is NOT removed from persistent storage.
+		This operation returns true if the topic was successfully undeployed. otherwise it returns false.
+	</para>
+</section>
+<section><title>DestroyTopic</title>
+<para>
+	This operation lets you programmatically destroy a topic.
+</para>
+<para>
+	The topic is undeployed and then all its data is destroyed from the database.
+
+<warning><title>Warning</title>
+	<para>
+	Be careful when using this method since it will delete all data for the topic.
+	</para>
+</warning>				
+					This operation returns true if the topic was successfully destroyed. otherwise it returns false.
+	</para>
+	</section>
+<section><title>ListMessageCountersHTML</title>
+	<para>
+		This operation returns message counters in an easy to display HTML format.
+	</para>
+</section>
+<section><title>ResetAllMesageCounters</title>
+	<para>
+		This operation resets all message counters to zero.
+	</para>
+</section>
+<section><title>ResetAllMesageCounters</title>
+	<para>
+		This operation resets all message counter histories to zero.
+	</para>
+</section>
+<section><title>EnableMessageCounters</title>
+	<para>
+		This operation enables all message counters for all destinations. Message counters are disabled by default.
+	</para>
+</section>
+<section><title>DisableMessageCounters</title>
+	<para>
+		This operation disables all message counters for all destinations. Message counters are disabled by default.
+	</para>
+</section>
+<section><title>RetrievePreparedTransactions</title>
+	<para>
+		Retrieves a list of the Xids for all transactions currently in a prepared state on the node.
+	</para>
+</section>
+<section><title>ShowPreparedTransactions</title>
+	<para>
+		Retrieves a list of the Xids for all transactions currently in a prepared state on the node in an easy to display HTML format.
+	</para>
+</section>
+	
+	
+</section>
+
+
+
+
+
+
+
+
+
 </chapter>

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Microcontainer.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Microcontainer.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -6,14 +6,197 @@
 
 <para>JBoss Application Server 5.0 uses the microcontainer to integrate enterprise services together with a Servlet/JSP container, EJB container, deployers and management utilities in order to provide a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. Likewise you are free to remove any services that you don't need simply by changing the configuration. You can even use the microcontainer to do this in other environments such as Tomcat and GlassFish since you can plug in different classloading models during the service deployment phase.</para>
 <para>Since JBoss Microcontainer is very lightweight and deals with POJOs it can also be used to deploy services into a Java ME runtime environment. This opens up new possibilities for mobile applications that can now take advantage of enterprise services without requiring a full JEE application server. </para>
-<para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.</para>
+<para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.
+</para>
+
+<section><title>An overview of the Microcontainer modules</title>
 <para>
-	.....more content coming...
+
+	This section introduces the various Microcontainer modules. The figure below gives an overview of the modules.
+	
+	<inlinemediaobject>
+		<imageobject>
+			<imagedata fileref="images/microcontainer.png"/>
+		</imageobject>
+	</inlinemediaobject>
+	
+	<itemizedlist>
+		<listitem>
+			<para>	
+				<literal>aop-mc-int</literal> handles integration between the JBossAOP and Microcontainer projects
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				The <literal>container</literal> module contains: reflection, the integration point for manipulating class information at runtime, e.g. overriding annotations or obtaining an aop instance advisor. joinpoint, the joinpoint model including the join point factory. classadaptor, the integration and configuration spi. metadata, base metadata types and repository
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>dependency</literal> management is handled by the controller. The controller is the core component for keeping track of contexts to make sure the configuration and lifecycle are done in the correct order including dependencies and classloading considerations.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>deployers</literal> load components from various models, POJOs, JMX, spring, Java EE, etc. into the Microcontainer runtime.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>kernel</literal> kernel defines the core kernel spi including, boostrap, configuration, POJO deployments, dependency, events, bean metadata, and bean registry.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				The <literal>managed</literal> module defines the base objects defining the management view of a component.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				The <literal>metatype</literal> metatype module defines the base types found in the management view of a component.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>osgi-int</literal> contains the integration classes that adapt the OSGi model onto the Microcontainer.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>spring-int</literal> contains the integration classes that adapt the spring model onto the Microcontainer. 
+			</para>
+		</listitem>
+	</itemizedlist>
+	
+			</para>
+</section>
+
+<section><title>Configuration</title>
+	<para>To configure your microcontainer the you can use the  <emphasis>JBOSS_HOME/server/&lt;server_configuration&gt;/conf/bootstrap-beans.xml</emphasis> and <emphasis>JBOSS_HOME/server/&lt;server_configuration&gt;/conf/bootstrap-repo-beans.xml</emphasis> files where <emphasis>&lt;server_configuration&gt;</emphasis> represents the <emphasis>all</emphasis>, <emphasis>default</emphasis> or <emphasis>minimal</emphasis> JBoss AS configurations. The configuration files have comments to guide you on the specific configurations available as illustrated by the example below. 
+	</para>
+<programlisting role="XML">
+	&lt;deployment xmlns="urn:jboss:bean-deployer:2.0"&gt;
+		
+		&lt;!-- All beans use the bootstrap classloader --&gt;
+		&lt;classloader&gt;&lt;inject bean="BootstrapClassLoader"/&gt;&lt;/classloader&gt;
+		
+		&lt;!-- TODO Should split this file up and use the new classloader --&gt;
+		&lt;bean name="BootstrapClassLoader" class="org.jboss.system.NoAnnotationURLClassLoader"&gt;
+		&lt;classloader&gt;&lt;null/&gt;&lt;/classloader&gt;
+			&lt;constructor factoryClass="org.jboss.system.NoAnnotationURLClassLoader" factoryMethod="createClassLoader"&gt;
+		&lt;parameter&gt;
+.....
+......
+&lt;bean name="ProfileServiceBootstrap" class="org.jboss.system.server.profileservice.ProfileServiceBootstrap"&gt;
+&lt;property name="kernel"&gt;&lt;inject bean="jboss.kernel:service=Kernel"/&gt;&lt;/property&gt;
+&lt;/bean&gt;
+
+&lt;!-- The legacy JMX kernel --&gt;
+&lt;bean name="JMXKernel" class="org.jboss.system.server.jmx.JMXKernel"&gt;
+&lt;property name="kernel"&gt;&lt;inject bean="jboss.kernel:service=Kernel"/&gt;&lt;/property&gt;
+	&lt;property name="serverImpl"&gt;&lt;inject bean="JBossServer"/&gt;&lt;/property&gt;
+	&lt;property name="oldClassLoader"&gt;false&lt;/property&gt;
+&lt;/bean&gt;
+....(content truncated)
+......
+
+	&lt;!-- The ManagedDeploymentCreator implementation --&gt;
+	&lt;bean name="ManagedDeploymentCreator" 	class="org.jboss.deployers.plugins.managed.DefaultManagedDeploymentCreator" /&gt;
+   
+	&lt;!-- The holder for deployers that determine structure --&gt;
+	&lt;bean name="StructuralDeployers" 		class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl"&gt;
+		&lt;property name="structureBuilder"&gt;
+		&lt;!-- The consolidator of the structure information --&gt;
+		&lt;bean name="StructureBuilder" 		class="org.jboss.deployers.vfs.plugins.structure.VFSStructureBuilder"/&gt;
+	&lt;/property&gt;
+	&lt;!-- Accept any implementor of structure deployer --&gt;
+	&lt;incallback method="addDeployer"/&gt;
+	&lt;uncallback method="removeDeployer"/&gt;
+&lt;/bean&gt;
+...(content truncated)
+...
+</programlisting>
+
+<para>The main beans are:
+	<itemizedlist>
+		<listitem>
+			<para><emphasis>ProfileService</emphasis> : this bean loads the deployments associated with the named server profile, "default", "all" or whatever name is passed in as the "-c" option to the server. Its an extension of the jboss-4.0.x and earlier notion of always looking to the filesystem <literal>server/name/conf/jboss-service.xml</literal> and <literal>server/name/deploy</literal> to load deployments.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>AspectManager?</emphasis> : the AOP aspects
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>MainDeployer</emphasis> : this bean is an update of the JMX based MainDeployer from earlier versions to a one based on the Microcontainer, JBoss5VirtualFileSystem, and Virtual Deployment Framework(VDF). Deployer aspects are registered with the MainDeployer as an ordered list via inject of the deployers property.
+		</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>ServiceClassLoaderDeployer?</emphasis> : this bean manages the class loading aspect of deployment.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>JARDeployer</emphasis> : this bean is a structural deployment aspect which handles the legacy nested deployment behavior of adding non-deployable jars to the current deployment classpath.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>FileStructure?</emphasis> : this bean is a structural deployment aspect which recognizes well know deployment file types specified by suffix.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>AspectDeployer?</emphasis> : handles aop descriptor deployments.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>BeanDeployer?</emphasis> : this bean translates deployer-beans.xml into KernelDeployment? for the descriptor beans.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>KernelDeploymentDeployer?</emphasis> : translates a KernelDeployment? into the constituent BeanMetaData instances for the kernel beans.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>BeanMetaDataDeployer?</emphasis> : creates the kernel beans from the deployment BeanMetaData.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>SARDeployer</emphasis> : this bean is a port of the legacy JMX SARDeployer to the VDF. It handles the legacy jboss-service.xml style of mbean deployment descriptors and maps this into a ServiceDeployment? pojo.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>ServiceDeploymentDeployer?</emphasis> : translates ServiceDeployment? pojo into the constituent ServiceMetaData that represent the various mbeans.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>ServiceDeployer?</emphasis> : creates the mbean services from deployment ServiceMetaData instances.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>JMXKernel</emphasis> : this bean manages the instantiation of a JMX kernel and MBeanServer in the jboss domain. It is used by the SARDeployer. It will be used by other management deployment aspects in the future to expose kernel beans via JMX.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>VFSDeployerScanner?</emphasis> : a scanner bean that loads the deployers directory contents into the basic profile service.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>VFSDeploymentScanner?</emphasis> : a scanner bean that loads the deploy directory contents into the basic profile service.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>HDScanner</emphasis> : a bean that queries the profile service for changes in deploy directory contents and redeploys updated content, undeploys removed content, and add new deployment content to the profile service.
+			</para>
+		</listitem>
+	</itemizedlist>
+
 </para>
 
-<section>
-	<title>References</title>
-<para>More information on the JBoss Microcontainer project can be obtained from <ulink url="http://labs.jboss.com/jbossmc/"/> </para>.
 </section>
 
+
+
+<section><title>References</title>
+<para>More information on the JBoss Microcontainer project can be obtained from <ulink url="http://labs.jboss.com/jbossmc/"/>. </para>
+</section>
+
 </chapter>

Added: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Remoting.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Remoting.xml	                        (rev 0)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Remoting.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -0,0 +1,13 @@
+<?xml version='1.0'?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+	  ]>
+
+<chapter id="remoting"><title>Remoting</title>
+	
+	<para>
+		The main objective of JBoss Remoting is to provide a single API for most network based invocations and related service that uses pluggable transports and data marshallers. The JBoss Remoting API provides the ability for making synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. The intention is to allow for the addition of different transports to fit different needs, yet still maintain the same API for making the remote invocations and only requiring configuration changes, not code changes, to fit these different needs.
+    </para>
+
+
+
+</chapter>
\ No newline at end of file

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Transactions.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Transactions.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Transactions.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -3,7 +3,6 @@
 ]>
 <chapter id="transaction"><title>JBoss Transactions</title>
 
-<para>With over 20 years of expertise in the area of transaction processing, JBoss Transactions (JBossTS) is the premier open source transaction manager. It can be deployed within a range of application servers, containers or run stand-alone. Over the past 20 years it has been used extensively within industry and to drive standards including the OMG and Web Services. </para>
 <para>JBoss Transactions runs in the <emphasis>all</emphasis> server configurations or customized configurations based on the <emphasis>all</emphasis> configuration. </para>
 <para>
 <inlinegraphic fileref="images/transactions-architecture.png" width=""/>
@@ -17,13 +16,13 @@
 </section>
 
 
-<section><title>JBoss Transactions J2EE Support</title>
+<section><title>JBoss Transactions Java EE 5 Support</title>
 <para>In the modern business environment of system consolidations, worldwide utilization, and "always- on" availability, enterprises need distributed transaction processing infrastructure to build reliable, sophisticated business applications that can guarantee absolute completion and accuracy of business processes. Transaction services ensure that sequences of database updates have been accurately and reliably committed as a single complete unit of work or that, in the event of failure, the database information is recovered. "Multimodal Transaction Processing" is the term coined by Gartner to describe the new generation of transactional application required to face the challenges posed by new business requirements, technologies and innovative computing architectures. </para>
 <note>
 <para>"Multimodal transaction processing will emerge. Users' adoption of client/server, the Internet, service-oriented architecture, Web services, mobile and wireless devices, and event-driven architectures means that the next generation of transaction processing applications will have to be implemented in very different ways to respond to new business strategies, including multichannel, the real-time enterprise and business process fusion." Predicts 2004: Prepare for Multimodal Transaction Processing, M. Pezzini, Gartner, 19 December 2003 </para></note>
 
 <para>JBossTS is a middleware solution that supports mission-critical applications in distributed computing environments. It plays a critical role in building reliable, sophisticated e-business applications guaranteeing absolute completion and accuracy of business processes. JBossTS supports "multimodal transaction processing" by enabling reliable transactions to span from front-end e-commerce applications to back office systems and beyond the enterprise firewall to business partners - across any system, anywhere in the world. </para>
-<para>Building on the industry proven J2EE transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The product supports the WS-AtomicTransaction and WS-BusinessActivity specifications. </para>
+<para>Building on the industry proven Java EE 5 transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The product supports the WS-AtomicTransaction and WS-BusinessActivity specifications. </para>
 </section>
 
 <section>
@@ -62,8 +61,8 @@
 
 <section>
 	<title>How does JBossTS address these issues?</title>
-<para>Building on the industry proven J2EE transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The programming interfaces are based on the Java API for XML Transactioning (JAXTX) and the product includes protocol support for the WS-AtomicTransaction and WS-BusinessActivity specifications. JBossTS 4.2 is designed to support multiple coordination protocols and therefore helps to future-proof transactional applications. For a more detailed description of the product capabilities, see the full feature list below for more details. </para>
-<para>JBossTS is a pure Java multi-modal transaction service that supports distributed transactions in CORBA, J2EE and Web services environments.</para>
+<para>Building on the industry proven JEE transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The programming interfaces are based on the Java API for XML Transactioning (JAXTX) and the product includes protocol support for the WS-AtomicTransaction and WS-BusinessActivity specifications. JBossTS 4.2 is designed to support multiple coordination protocols and therefore helps to future-proof transactional applications. For a more detailed description of the product capabilities, see the full feature list below for more details. </para>
+<para>JBossTS is a pure Java multi-modal transaction service that supports distributed transactions in CORBA, JEE and Web services environments.</para>
 <orderedlist>
 <listitem>
 <para>Standards compliance </para>
@@ -72,7 +71,7 @@
 <para>CORBA Object Transaction Service (OTS) </para>
 </listitem>
 <listitem>
-<para>Java Enterprise (J2EE) transactions </para>
+<para>Java Enterprise (JEE) transactions </para>
 <orderedlist>
 <listitem>
 <para>Java Transaction API (JTA) </para>
@@ -99,7 +98,7 @@
 </orderedlist>
 </listitem>
 <listitem>
-<para>J2EE and CORBA transactioning features </para>
+<para>JEE and CORBA transactioning features </para>
 <orderedlist>
 <listitem>
 <para>Complete distributed transaction support </para>
@@ -167,7 +166,7 @@
 <para>Architected for portability across a wide- range of Web services platforms. Supports the open source JBoss application server for highly cost effective development and deployment. </para>
 </listitem>
 <listitem>
-<para>Close integration with enterprise Java standards, allowing Web services transactions to seamlessly integrate with J2EE application servers, messaging systems and database back- ends. </para>
+<para>Close integration with enterprise Java standards, allowing Web services transactions to seamlessly integrate with JEE application servers, messaging systems and database back- ends. </para>
 </listitem>
 <listitem>
 <para>Easy to use Java programming interfaces, based on the emerging JAXTX standard. A rich programming framework reduces overhead in adding transactioning capabilities to Web services. </para>

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Web_Services.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Web_Services.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/Web_Services.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -18,7 +18,7 @@
 		JBossWS integrates with most current JBoss Application Server releases as well as earlier ones, that did implement the J2EE 1.4 specifications. Even though JAX-RPC, the web service specification for J2EE 1.4, is still supported JBossWS does put a clear focus on JAX-WS. 
 	</para>
 	<section><title>Who needs web services?</title> 
-		<para>
+	<para>
 		Enterprise systems communication may benefit from a wise adoption of WS technologies. Exposing well designed contracts allows developers to extract an abstract view of their service capabilities. Considering the standardized way contracts are written, this definitely helps communication with third-party systems and eventually support business-to-business integration. No more agreement required on vendor specific implementation details, home-brew communication protocol or custom per-customer settings. Everything is clear and standardized in the contract the provider and consumer agree on. Of course this also reduces the dependencies between implementations allowing other consumers to easily use the provided service without major changes. 
 	</para>
 	<para>
@@ -198,12 +198,13 @@
 
 
 	
-	<section><title>The MTOM enabled SOAP 1.1 binding ID</title> 
+<section><title>The MTOM enabled SOAP 1.1 binding ID</title> 
+<para>
+	MTOM enabled clients
+</para> 
 	<para>
-	MTOM enabled clients</para> 
-	<para>
 	Web service clients can use the same approach described above or rely on the Binding API to enable MTOM (Excerpt taken from the <literal>org.jboss.test.ws.jaxws.samples.xop.doclit.XOPTestCase</literal>): 
-</para>
+	</para>
 
 <programlisting role="JAVA">[...] 
 	Service service = Service.create(wsdlURL, serviceName); 
@@ -216,14 +217,14 @@
 
 </section>
 
-<para>	to do list</para>
-<para>- JBoss Web Services 2.0.3.GA</para> 
-<para>- Attachment Support with XOP and SwA</para> 
+<!--<para>	to do list</para>
+<para>- JBoss Web Services 2.0.3.GA</para>
+<para>- Attachment Support with XOP and SwA</para>
 <para>- JMS Transport </para>
-<para>- WS-Addressing</para> 
+<para>- WS-Addressing</para>
 <para>- WS-Security </para>
 <para>- WS-Policy </para>
-<para>- WS-Eventing</para>
+<para>- WS-Eventing</para>-->
 
 </section>
 	

Modified: projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/resolved.xml
===================================================================
--- projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/resolved.xml	2008-05-23 02:00:34 UTC (rev 73605)
+++ projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/en-US/resolved.xml	2008-05-23 02:00:35 UTC (rev 73606)
@@ -1,6 +1,983 @@
 <?xml version="1.0"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
-<book>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY uArr "⇑">
+<!ENTITY hcirc "ĥ">
+<!ENTITY icirc "î">
+<!ENTITY equals "=">
+<!ENTITY cong "≅">
+<!ENTITY HARDcy "Ъ">
+<!ENTITY icy "и">
+<!ENTITY Ecaron "Ě">
+<!ENTITY clubs "♣">
+<!ENTITY phmmat "ℳ">
+<!ENTITY sqcap "⊓">
+<!ENTITY thorn "þ">
+<!ENTITY Lcedil "Ļ">
+<!ENTITY rarr "→">
+<!ENTITY verbar "|">
+<!ENTITY cire "≗">
+<!ENTITY DZcy "Џ">
+<!ENTITY b.delta "𝛅">
+<!ENTITY Gcirc "Ĝ">
+<!ENTITY ocir "⊚">
+<!ENTITY circ "ˆ">
+<!ENTITY Igr "Ι">
+<!ENTITY udigr "ϋ">
+<!ENTITY prime "′">
+<!ENTITY npr "⊀">
+<!ENTITY b.pi "𝛑">
+<!ENTITY frac58 "⅝">
+<!ENTITY ldquor "„">
+<!ENTITY sqsup "⊐">
+<!ENTITY boxDR "╔">
+<!ENTITY kcedil "ķ">
+<!ENTITY vDash "⊨">
+<!ENTITY Scedil "Ş">
+<!ENTITY perp "⊥">
+<!ENTITY b.Gamma "𝚪">
+<!ENTITY b.kappa "𝛋">
+<!ENTITY Uuml "Ü">
+<!ENTITY mnplus "∓">
+<!ENTITY nearr "↗">
+<!ENTITY nrtri "⋫">
+<!ENTITY cupre "≼">
+<!ENTITY boxV "║">
+<!ENTITY Zdot "Ż">
+<!ENTITY pound "£">
+<!ENTITY lharu "↼">
+<!ENTITY boxdr "┌">
+<!ENTITY ocy "о">
+<!ENTITY xgr "ξ">
+<!ENTITY b.xi "𝛏">
+<!ENTITY larr "←">
+<!ENTITY middot "·">
+<!ENTITY xrArr "⟹">
+<!ENTITY Ncy "Н">
+<!ENTITY acute "´">
+<!ENTITY phis "ϕ">
+<!ENTITY ncedil "ņ">
+<!ENTITY lAarr "⇚">
+<!ENTITY sqsube "⊑">
+<!ENTITY quot '"'>
+<!ENTITY TSHcy "Ћ">
+<!ENTITY b.Gammad "Ϝ">
+<!ENTITY amacr "ā">
+<!ENTITY otimes "⊗">
+<!ENTITY inodot "ı">
+<!ENTITY gsdot "⋗">
+<!ENTITY LJcy "Љ">
+<!ENTITY phiv "φ">
+<!ENTITY odblac "ő">
+<!ENTITY filig "fi">
+<!ENTITY amalg "⨿">
+<!ENTITY sdotb "⊡">
+<!ENTITY boxDL "╗">
+<!ENTITY Theta "Θ">
+<!ENTITY cdot "ċ">
+<!ENTITY ordm "º">
+<!ENTITY atilde "ã">
+<!ENTITY squf "▪">
+<!ENTITY notin "∉">
+<!ENTITY nmid "∤">
+<!ENTITY shchcy "щ">
+<!ENTITY lfloor "⌊">
+<!ENTITY Xi "Ξ">
+<!ENTITY Hstrok "Ħ">
+<!ENTITY period ".">
+<!ENTITY nldr "‥">
+<!ENTITY numsp " ">
+<!ENTITY boxdl "┐">
+<!ENTITY Fcy "Ф">
+<!ENTITY tscy "ц">
+<!ENTITY Iukcy "І">
+<!ENTITY cross "✗">
+<!ENTITY ohgr "ω">
+<!ENTITY nbsp " ">
+<!ENTITY ni "∋">
+<!ENTITY comp "∁">
+<!ENTITY boxH "═">
+<!ENTITY b.Delta "𝚫">
+<!ENTITY Oslash "Ø">
+<!ENTITY marker "▮">
+<!ENTITY ndash "–">
+<!ENTITY ordf "ª">
+<!ENTITY nsce "⪰̸">
+<!ENTITY vrtri "⊳">
+<!ENTITY ubrcy "ў">
+<!ENTITY Ccirc "Ĉ">
+<!ENTITY quest "?">
+<!ENTITY ne "≠">
+<!ENTITY gap "⪆">
+<!ENTITY efDot "≒">
+<!ENTITY rcy "р">
+<!ENTITY bsim "∽">
+<!ENTITY bgr "β">
+<!ENTITY omacr "ō">
+<!ENTITY umacr "ū">
+<!ENTITY lpar "(">
+<!ENTITY uharl "↿">
+<!ENTITY Gcy "Г">
+<!ENTITY ast "*">
+<!ENTITY acy "а">
+<!ENTITY thetas "θ">
+<!ENTITY uring "ů">
+<!ENTITY Zcaron "Ž">
+<!ENTITY horbar "―">
+<!ENTITY star "☆">
+<!ENTITY timesb "⊠">
+<!ENTITY npre "⪯̸">
+<!ENTITY real "ℜ">
+<!ENTITY dlarr "↙">
+<!ENTITY nrArr "⇏">
+<!ENTITY oplus "⊕">
+<!ENTITY Xgr "Ξ">
+<!ENTITY ucy "у">
+<!ENTITY thetav "ϑ">
+<!ENTITY jcirc "ĵ">
+<!ENTITY uharr "↾">
+<!ENTITY mgr "μ">
+<!ENTITY hearts "♥">
+<!ENTITY nvDash "⊭">
+<!ENTITY yicy "ї">
+<!ENTITY dot "˙">
+<!ENTITY alpha "α">
+<!ENTITY wedgeq "≙">
+<!ENTITY bowtie "⋈">
+<!ENTITY boxDr "╓">
+<!ENTITY b.upsi "𝛖">
+<!ENTITY euml "ë">
+<!ENTITY vArr "⇕">
+<!ENTITY lgr "λ">
+<!ENTITY b.rhov "𝛠">
+<!ENTITY ubreve "ŭ">
+<!ENTITY copysr "℗">
+<!ENTITY cap "∩">
+<!ENTITY aogon "ą">
+<!ENTITY racute "ŕ">
+<!ENTITY rthree "⋌">
+<!ENTITY Sgr "Σ">
+<!ENTITY uacute "ú">
+<!ENTITY Tcaron "Ť">
+<!ENTITY dagger "†">
+<!ENTITY oast "⊛">
+<!ENTITY prnE "⪵">
+<!ENTITY thkap "≈">
+<!ENTITY boxdR "╒">
+<!ENTITY dgr "δ">
+<!ENTITY nacute "ń">
+<!ENTITY hardcy "ъ">
+<!ENTITY sqsupe "⊒">
+<!ENTITY TScy "Ц">
+<!ENTITY reg "®">
+<!ENTITY cir "○">
+<!ENTITY lsquor "‚">
+<!ENTITY ycy "ы">
+<!ENTITY Sigma "Σ">
+<!ENTITY Gbreve "Ğ">
+<!ENTITY order "ℴ">
+<!ENTITY nlarr "↚">
+<!ENTITY eng "ŋ">
+<!ENTITY sacute "ś">
+<!ENTITY ensp " ">
+<!ENTITY rarr2 "⇉">
+<!ENTITY coprod "∐">
+<!ENTITY iacgr "ί">
+<!ENTITY b.piv "𝛡">
+<!ENTITY rlhar2 "⇌">
+<!ENTITY boxDl "╖">
+<!ENTITY Pcy "П">
+<!ENTITY Dagger "‡">
+<!ENTITY khcy "х">
+<!ENTITY sigma "σ">
+<!ENTITY nltrie "⋬">
+<!ENTITY gjcy "ѓ">
+<!ENTITY b.alpha "𝛂">
+<!ENTITY plusmn "±">
+<!ENTITY scnap "⪺">
+<!ENTITY vprime "′">
+<!ENTITY iota "ι">
+<!ENTITY Dcaron "Ď">
+<!ENTITY emsp " ">
+<!ENTITY trie "≜">
+<!ENTITY boxdL "╕">
+<!ENTITY cacute "ć">
+<!ENTITY rcedil "ŗ">
+<!ENTITY lhblk "▄">
+<!ENTITY lnsim "⋦">
+<!ENTITY bsime "⋍">
+<!ENTITY Vvdash "⊪">
+<!ENTITY zgr "ζ">
+<!ENTITY Ncaron "Ň">
+<!ENTITY rcaron "ř">
+<!ENTITY radic "√">
+<!ENTITY colone "≔">
+<!ENTITY Ucy "У">
+<!ENTITY lcub "{">
+<!ENTITY mdash "—">
+<!ENTITY ogon "˛">
+<!ENTITY Lgr "Λ">
+<!ENTITY b.chi "𝛘">
+<!ENTITY Barwed "⌆">
+<!ENTITY odot "⊙">
+<!ENTITY softcy "ь">
+<!ENTITY yucy "ю">
+<!ENTITY Ogr "Ο">
+<!ENTITY ecirc "ê">
+<!ENTITY Uacute "Ú">
+<!ENTITY jcy "й">
+<!ENTITY Oacgr "Ό">
+<!ENTITY ntilde "ñ">
+<!ENTITY Uring "Ů">
+<!ENTITY Udigr "Ϋ">
+<!ENTITY squ "□">
+<!ENTITY Uacgr "Ύ">
+<!ENTITY uarr "↑">
+<!ENTITY sim "∼">
+<!ENTITY egr "ε">
+<!ENTITY aleph "ℵ">
+<!ENTITY nharr "↮">
+<!ENTITY kcy "к">
+<!ENTITY Rgr "Ρ">
+<!ENTITY ffilig "ffi">
+<!ENTITY boxvl "┤">
+<!ENTITY Iacgr "Ί">
+<!ENTITY ang90 "∟">
+<!ENTITY nrarr "↛">
+<!ENTITY nges "⩾̸">
+<!ENTITY nsube "⊈">
+<!ENTITY nsup "⊅">
+<!ENTITY egs "⪖">
+<!ENTITY acirc "â">
+<!ENTITY Yuml "Ÿ">
+<!ENTITY ltrif "◂">
+<!ENTITY lagran "ℒ">
+<!ENTITY npar "∦">
+<!ENTITY scsim "≿">
+<!ENTITY boxvr "├">
+<!ENTITY Acirc "Â">
+<!ENTITY Ucirc "Û">
+<!ENTITY zcaron "ž">
+<!ENTITY shy "­">
+<!ENTITY ominus "⊖">
+<!ENTITY frac38 "⅜">
+<!ENTITY incare "℅">
+<!ENTITY uhblk "▀">
+<!ENTITY lEg "⪋">
+<!ENTITY gcy "г">
+<!ENTITY b.eta "𝛈">
+<!ENTITY lnap "⪉">
+<!ENTITY Iacute "Í">
+<!ENTITY yacute "ý">
+<!ENTITY dstrok "đ">
+<!ENTITY Imacr "Ī">
+<!ENTITY orarr "↻">
+<!ENTITY Eacgr "Έ">
+<!ENTITY apos "'">
+<!ENTITY b.epsiv "𝛜">
+<!ENTITY gcirc "ĝ">
+<!ENTITY udblac "ű">
+<!ENTITY planck "ℏ">
+<!ENTITY upsi "υ">
+<!ENTITY b.Lambda "𝚲">
+<!ENTITY Bgr "Β">
+<!ENTITY scedil "ş">
+<!ENTITY Rarr "↠">
+<!ENTITY nrtrie "⋭">
+<!ENTITY nsub "⊄">
+<!ENTITY vcy "в">
+<!ENTITY Eacute "É">
+<!ENTITY boxvh "┼">
+<!ENTITY dcy "д">
+<!ENTITY Aring "Å">
+<!ENTITY Igrave "Ì">
+<!ENTITY utilde "ũ">
+<!ENTITY divonx "⋇">
+<!ENTITY lne "⪇">
+<!ENTITY scnE "⪶">
+<!ENTITY ccedil "ç">
+<!ENTITY supne "⊋">
+<!ENTITY empty "∅">
+<!ENTITY b.nu "𝛎">
+<!ENTITY top "⊤">
+<!ENTITY lcy "л">
+<!ENTITY b.gamma "𝛄">
+<!ENTITY aelig "æ">
+<!ENTITY iuml "ï">
+<!ENTITY Lcaron "Ľ">
+<!ENTITY bottom "⊥">
+<!ENTITY rarrhk "↪">
+<!ENTITY DScy "Ѕ">
+<!ENTITY idiagr "ΐ">
+<!ENTITY imacr "ī">
+<!ENTITY ltri "◃">
+<!ENTITY infin "∞">
+<!ENTITY le "≤">
+<!ENTITY sime "≃">
+<!ENTITY kappa "κ">
+<!ENTITY kappav "ϰ">
+<!ENTITY OElig "Œ">
+<!ENTITY urcrop "⌎">
+<!ENTITY darr2 "⇊">
+<!ENTITY lg "≶">
+<!ENTITY spar "∥">
+<!ENTITY Mgr "Μ">
+<!ENTITY rtri "▹">
+<!ENTITY daleth "ℸ">
+<!ENTITY sfrown "⌢">
+<!ENTITY epsiv "ε">
+<!ENTITY Omega "Ω">
+<!ENTITY colon ":">
+<!ENTITY prop "∝">
+<!ENTITY lArr "⇐">
+<!ENTITY Upsi "ϒ">
+<!ENTITY oslash "ø">
+<!ENTITY ap "≈">
+<!ENTITY Sup "⋑">
+<!ENTITY epsis "ϵ">
+<!ENTITY b.omega "𝛚">
+<!ENTITY rpar ")">
+<!ENTITY Abreve "Ă">
+<!ENTITY mldr "…">
+<!ENTITY ltrie "⊴">
+<!ENTITY Psi "Ψ">
+<!ENTITY Agrave "À">
+<!ENTITY Tcedil "Ţ">
+<!ENTITY auml "ä">
+<!ENTITY lcedil "ļ">
+<!ENTITY scirc "ŝ">
+<!ENTITY larrhk "↩">
+<!ENTITY varr "↕">
+<!ENTITY ncong "≇">
+<!ENTITY jnodot "j">
+<!ENTITY subE "⫅">
+<!ENTITY kjcy "ќ">
+<!ENTITY larr2 "⇇">
+<!ENTITY rsh "↱">
+<!ENTITY sdot "⋅">
+<!ENTITY wreath "≀">
+<!ENTITY cuepr "⋞">
+<!ENTITY frown "⌢">
+<!ENTITY Agr "Α">
+<!ENTITY uacgr "ύ">
+<!ENTITY rcub "}">
+<!ENTITY dharl "⇃">
+<!ENTITY bcy "б">
+<!ENTITY Tgr "Τ">
+<!ENTITY diam "⋄">
+<!ENTITY eacute "é">
+<!ENTITY xlArr "⟸">
+<!ENTITY leg "⋚">
+<!ENTITY boxvL "╡">
+<!ENTITY Kcy "К">
+<!ENTITY ncy "н">
+<!ENTITY sgr "σ">
+<!ENTITY beta "β">
+<!ENTITY exist "∃">
+<!ENTITY bprime "‵">
+<!ENTITY boxul "┘">
+<!ENTITY Zcy "З">
+<!ENTITY Iuml "Ï">
+<!ENTITY Scaron "Š">
+<!ENTITY sol "/">
+<!ENTITY boxvR "╞">
+<!ENTITY fcy "ф">
+<!ENTITY Egrave "È">
+<!ENTITY Utilde "Ũ">
+<!ENTITY lthree "⋋">
+<!ENTITY boxur "└">
+<!ENTITY dharr "⇂">
+<!ENTITY uarr2 "⇈">
+<!ENTITY lacute "ĺ">
+<!ENTITY spades "♠">
+<!ENTITY int "∫">
+<!ENTITY rect "▭">
+<!ENTITY compfn "∘">
+<!ENTITY b.sigma "𝛔">
+<!ENTITY Amacr "Ā">
+<!ENTITY prod "∏">
+<!ENTITY rpargt "⦔">
+<!ENTITY b.sigmav "𝛓">
+<!ENTITY excl "!">
+<!ENTITY fnof "ƒ">
+<!ENTITY beth "ℶ">
+<!ENTITY yuml "ÿ">
+<!ENTITY rsquo "’">
+<!ENTITY pr "≺">
+<!ENTITY ccaron "č">
+<!ENTITY hyphen "‐">
+<!ENTITY weierp "℘">
+<!ENTITY smile "⌣">
+<!ENTITY Egr "Ε">
+<!ENTITY eeacgr "ή">
+<!ENTITY nsc "⊁">
+<!ENTITY les "⩽">
+<!ENTITY boxvH "╪">
+<!ENTITY KHcy "Х">
+<!ENTITY bernou "ℬ">
+<!ENTITY lpargt "⦠">
+<!ENTITY tgr "τ">
+<!ENTITY zacute "ź">
+<!ENTITY amp "&#38;">
+<!ENTITY lnE "≨">
+<!ENTITY nlE "≦̸">
+<!ENTITY sbsol "﹨">
+<!ENTITY Pi "Π">
+<!ENTITY b.beta "𝛃">
+<!ENTITY b.mu "𝛍">
+<!ENTITY Ograve "Ò">
+<!ENTITY phone "☎">
+<!ENTITY iff "⇔">
+<!ENTITY gsim "≳">
+<!ENTITY rx "℞">
+<!ENTITY there4 "∴">
+<!ENTITY harrw "↭">
+<!ENTITY udiagr "ΰ">
+<!ENTITY otilde "õ">
+<!ENTITY DotDot " ⃜">
+<!ENTITY lrhar2 "⇋">
+<!ENTITY lE "≦">
+<!ENTITY hstrok "ħ">
+<!ENTITY Racute "Ŕ">
+<!ENTITY rarrw "↝">
+<!ENTITY angmsd "∡">
+<!ENTITY tshcy "ћ">
+<!ENTITY szlig "ß">
+<!ENTITY nequiv "≢">
+<!ENTITY pcy "п">
+<!ENTITY darr "↓">
+<!ENTITY female "♀">
+<!ENTITY curarr "↷">
+<!ENTITY minusb "⊟">
+<!ENTITY aacute "á">
+<!ENTITY Dcy "Д">
+<!ENTITY THORN "Þ">
+<!ENTITY ucirc "û">
+<!ENTITY asymp "≈">
+<!ENTITY bcong "≌">
+<!ENTITY die "¨">
+<!ENTITY ograve "ò">
+<!ENTITY iexcl "¡">
+<!ENTITY frac56 "⅚">
+<!ENTITY rArr "⇒">
+<!ENTITY tprime "‴">
+<!ENTITY osol "⊘">
+<!ENTITY sqsub "⊏">
+<!ENTITY rho "ρ">
+<!ENTITY b.psi "𝛙">
+<!ENTITY aring "å">
+<!ENTITY Edot "Ė">
+<!ENTITY lcaron "ľ">
+<!ENTITY rlarr2 "⇄">
+<!ENTITY EEacgr "Ή">
+<!ENTITY pi "π">
+<!ENTITY sect "§">
+<!ENTITY bepsi "϶">
+<!ENTITY ffllig "ffl">
+<!ENTITY lsh "↰">
+<!ENTITY dscy "ѕ">
+<!ENTITY macr "¯">
+<!ENTITY b.kappav "𝛞">
+<!ENTITY scaron "š">
+<!ENTITY commat "@">
+<!ENTITY dollar "$">
+<!ENTITY angsph "∢">
+<!ENTITY Udblac "Ű">
+<!ENTITY comma ",">
+<!ENTITY copy "©">
+<!ENTITY diams "♦">
+<!ENTITY Dot "¨">
+<!ENTITY sube "⊆">
+<!ENTITY Cap "⋒">
+<!ENTITY nsmid "∤">
+<!ENTITY SOFTcy "Ь">
+<!ENTITY eegr "η">
+<!ENTITY lsim "≲">
+<!ENTITY ssmile "⌣">
+<!ENTITY nlt "≮">
+<!ENTITY boxHU "╩">
+<!ENTITY ZHcy "Ж">
+<!ENTITY abreve "ă">
+<!ENTITY lmidot "ŀ">
+<!ENTITY angst "Å">
+<!ENTITY b.lambda "𝛌">
+<!ENTITY uuml "ü">
+<!ENTITY ENG "Ŋ">
+<!ENTITY IJlig "IJ">
+<!ENTITY brvbar "¦">
+<!ENTITY esdot "≐">
+<!ENTITY boxuL "╛">
+<!ENTITY blk14 "░">
+<!ENTITY YAcy "Я">
+<!ENTITY caron "ˇ">
+<!ENTITY ohacgr "ώ">
+<!ENTITY sup3 "³">
+<!ENTITY flat "♭">
+<!ENTITY minus "−">
+<!ENTITY olarr "↺">
+<!ENTITY dlcorn "⌞">
+<!ENTITY boxuR "╘">
+<!ENTITY iukcy "і">
+<!ENTITY b.tau "𝛕">
+<!ENTITY Otilde "Õ">
+<!ENTITY ldquo "“">
+<!ENTITY lang "〈">
+<!ENTITY Verbar "‖">
+<!ENTITY ges "⩾">
+<!ENTITY prap "⪷">
+<!ENTITY thksim "∼">
+<!ENTITY Vcy "В">
+<!ENTITY yacy "я">
+<!ENTITY drcrop "⌌">
+<!ENTITY omega "ω">
+<!ENTITY Hcirc "Ĥ">
+<!ENTITY tstrok "ŧ">
+<!ENTITY ang "∠">
+<!ENTITY khgr "χ">
+<!ENTITY b.thetas "𝛉">
+<!ENTITY ecaron "ě">
+<!ENTITY Odblac "Ő">
+<!ENTITY fflig "ff">
+<!ENTITY lowast "∗">
+<!ENTITY nvdash "⊬">
+<!ENTITY frac18 "⅛">
+<!ENTITY sup1 "¹">
+<!ENTITY njcy "њ">
+<!ENTITY b.thetav "𝛝">
+<!ENTITY sup2 "²">
+<!ENTITY gimel "ℷ">
+<!ENTITY ldot "⋖">
+<!ENTITY Ccedil "Ç">
+<!ENTITY rdquo "”">
+<!ENTITY rhard "⇁">
+<!ENTITY nsime "≄">
+<!ENTITY boxhu "┴">
+<!ENTITY intcal "⊺">
+<!ENTITY nsupe "⊉">
+<!ENTITY Gt "≫">
+<!ENTITY igr "ι">
+<!ENTITY nabla "∇">
+<!ENTITY urcorn "⌝">
+<!ENTITY nle "≰">
+<!ENTITY Icy "И">
+<!ENTITY DJcy "Ђ">
+<!ENTITY jukcy "є">
+<!ENTITY lceil "⌈">
+<!ENTITY oS "Ⓢ">
+<!ENTITY malt "✠">
+<!ENTITY ccirc "ĉ">
+<!ENTITY ycirc "ŷ">
+<!ENTITY Aacgr "Ά">
+<!ENTITY Ntilde "Ñ">
+<!ENTITY vsupnE "⫌︀">
+<!ENTITY ogr "ο">
+<!ENTITY and "∧">
+<!ENTITY gvnE "≩︀">
+<!ENTITY dashv "⊣">
+<!ENTITY supE "⫆">
+<!ENTITY mu "μ">
+<!ENTITY vsubnE "⫋︀">
+<!ENTITY gE "≧">
+<!ENTITY smid "∣">
+<!ENTITY delta "δ">
+<!ENTITY tcaron "ť">
+<!ENTITY rsqb "]">
+<!ENTITY bull "•">
+<!ENTITY cuwed "⋏">
+<!ENTITY raquo "»">
+<!ENTITY frac45 "⅘">
+<!ENTITY part "∂">
+<!ENTITY Vdash "⊩">
+<!ENTITY boxhd "┬">
+<!ENTITY psi "ψ">
+<!ENTITY b.Omega "𝛀">
+<!ENTITY iquest "¿">
+<!ENTITY sqcup "⊔">
+<!ENTITY YUcy "Ю">
+<!ENTITY psgr "ψ">
+<!ENTITY conint "∮">
+<!ENTITY gel "⋛">
+<!ENTITY Icirc "Î">
+<!ENTITY twixt "≬">
+<!ENTITY boxHD "╦">
+<!ENTITY male "♂">
+<!ENTITY euro "€">
+<!ENTITY epsi "ϵ">
+<!ENTITY Rcaron "Ř">
+<!ENTITY SHCHcy "Щ">
+<!ENTITY ugr "υ">
+<!ENTITY Phi "Φ">
+<!ENTITY b.Xi "𝚵">
+<!ENTITY lt "&#60;">
+<!ENTITY scnsim "⋩">
+<!ENTITY models "⊧">
+<!ENTITY boxHu "╧">
+<!ENTITY Lcy "Л">
+<!ENTITY Sacute "Ś">
+<!ENTITY nwarr "↖">
+<!ENTITY drcorn "⌟">
+<!ENTITY NJcy "Њ">
+<!ENTITY mumap "⊸">
+<!ENTITY rAarr "⇛">
+<!ENTITY nsubE "⫅̸">
+<!ENTITY b.rho "𝛒">
+<!ENTITY oelig "œ">
+<!ENTITY utrif "▴">
+<!ENTITY subne "⊊">
+<!ENTITY para "¶">
+<!ENTITY ocirc "ô">
+<!ENTITY ouml "ö">
+<!ENTITY num "#">
+<!ENTITY boxUL "╝">
+<!ENTITY IEcy "Е">
+<!ENTITY Ocy "О">
+<!ENTITY Ugrave "Ù">
+<!ENTITY eogon "ę">
+<!ENTITY sum "∑">
+<!ENTITY mcy "м">
+<!ENTITY YIcy "Ї">
+<!ENTITY Gamma "Γ">
+<!ENTITY isin "∈">
+<!ENTITY cuesc "⋟">
+<!ENTITY b.Pi "𝚷">
+<!ENTITY Ubreve "Ŭ">
+<!ENTITY starf "★">
+<!ENTITY gne "⪈">
+<!ENTITY gammad "ϝ">
+<!ENTITY napos "ʼn">
+<!ENTITY sup "⊃">
+<!ENTITY dArr "⇓">
+<!ENTITY Larr "↞">
+<!ENTITY nVDash "⊯">
+<!ENTITY boxhU "╨">
+<!ENTITY Ggr "Γ">
+<!ENTITY Idigr "Ϊ">
+<!ENTITY AElig "Æ">
+<!ENTITY Idot "İ">
+<!ENTITY Lacute "Ĺ">
+<!ENTITY sharp "♯">
+<!ENTITY Ubrcy "Ў">
+<!ENTITY lsqb "[">
+<!ENTITY micro "µ">
+<!ENTITY Sub "⋐">
+<!ENTITY agr "α">
+<!ENTITY nap "≉">
+<!ENTITY sfgr "ς">
+<!ENTITY block "█">
+<!ENTITY nspar "∦">
+<!ENTITY supnE "⫌">
+<!ENTITY prsim "≾">
+<!ENTITY shcy "ш">
+<!ENTITY dblac "˝">
+<!ENTITY xhArr "⟺">
+<!ENTITY dtri "▿">
+<!ENTITY barwed "⌅">
+<!ENTITY zcy "з">
+<!ENTITY agrave "à">
+<!ENTITY par "∥">
+<!ENTITY vsupne "⊋︀">
+<!ENTITY Scy "С">
+<!ENTITY zdot "ż">
+<!ENTITY rsquor "’">
+<!ENTITY Delta "Δ">
+<!ENTITY nVdash "⊮">
+<!ENTITY Pgr "Π">
+<!ENTITY gamma "γ">
+<!ENTITY tau "τ">
+<!ENTITY Ecirc "Ê">
+<!ENTITY sung "♪">
+<!ENTITY natur "♮">
+<!ENTITY or "∨">
+<!ENTITY vsubne "⊊︀">
+<!ENTITY Jcy "Й">
+<!ENTITY square "□">
+<!ENTITY b.Psi "𝚿">
+<!ENTITY b.zeta "𝛇">
+<!ENTITY gbreve "ğ">
+<!ENTITY Kcedil "Ķ">
+<!ENTITY ohm "Ω">
+<!ENTITY frac35 "⅗">
+<!ENTITY ssetmn "∖">
+<!ENTITY boxUR "╚">
+<!ENTITY frac34 "¾">
+<!ENTITY target "⌖">
+<!ENTITY cularr "↶">
+<!ENTITY xcirc "◯">
+<!ENTITY boxhD "╥">
+<!ENTITY iecy "е">
+<!ENTITY Euml "Ë">
+<!ENTITY half "½">
+<!ENTITY rang "〉">
+<!ENTITY numero "№">
+<!ENTITY Ugr "Υ">
+<!ENTITY semi ";">
+<!ENTITY times "×">
+<!ENTITY rharu "⇀">
+<!ENTITY iocy "ё">
+<!ENTITY b.gammad "ϝ">
+<!ENTITY lozf "⧫">
+<!ENTITY thinsp " ">
+<!ENTITY plusb "⊞">
+<!ENTITY tilde "˜">
+<!ENTITY Aogon "Ą">
+<!ENTITY Eogon "Ę">
+<!ENTITY blk12 "▒">
+<!ENTITY pre "⪯">
+<!ENTITY boxHd "╤">
+<!ENTITY piv "ϖ">
+<!ENTITY ncaron "ň">
+<!ENTITY wcirc "ŵ">
+<!ENTITY utri "▵">
+<!ENTITY Prime "″">
+<!ENTITY cedil "¸">
+<!ENTITY idigr "ϊ">
+<!ENTITY curren "¤">
+<!ENTITY laquo "«">
+<!ENTITY ulcrop "⌏">
+<!ENTITY ring "˚">
+<!ENTITY oacute "ó">
+<!ENTITY Nacute "Ń">
+<!ENTITY permil "‰">
+<!ENTITY oacgr "ό">
+<!ENTITY frac78 "⅞">
+<!ENTITY blk34 "▓">
+<!ENTITY gnsim "⋧">
+<!ENTITY boxVH "╬">
+<!ENTITY zhcy "ж">
+<!ENTITY b.phiv "𝛟">
+<!ENTITY loz "◊">
+<!ENTITY Ngr "Ν">
+<!ENTITY phgr "φ">
+<!ENTITY b.iota "𝛊">
+<!ENTITY ETH "Ð">
+<!ENTITY trade "™">
+<!ENTITY Cup "⋓">
+<!ENTITY subnE "⫋">
+<!ENTITY PHgr "Φ">
+<!ENTITY xi "ξ">
+<!ENTITY Rcy "Р">
+<!ENTITY ggr "γ">
+<!ENTITY Lmidot "Ŀ">
+<!ENTITY Scirc "Ŝ">
+<!ENTITY rtrif "▸">
+<!ENTITY larrtl "↢">
+<!ENTITY eDot "≑">
+<!ENTITY boxVL "╣">
+<!ENTITY THgr "Θ">
+<!ENTITY Dstrok "Đ">
+<!ENTITY cent "¢">
+<!ENTITY odash "⊝">
+<!ENTITY boxUl "╜">
+<!ENTITY ape "≊">
+<!ENTITY gEl "⪌">
+<!ENTITY nltri "⋪">
+<!ENTITY Aacute "Á">
+<!ENTITY cuvee "⋎">
+<!ENTITY gnE "≩">
+<!ENTITY kgr "κ">
+<!ENTITY iogon "į">
+<!ENTITY rarrtl "↣">
+<!ENTITY b.phi "𝛗">
+<!ENTITY sccue "≽">
+<!ENTITY IOcy "Ё">
+<!ENTITY sext "✶">
+<!ENTITY uplus "⊎">
+<!ENTITY ecolon "≕">
+<!ENTITY nlArr "⇍">
+<!ENTITY scap "⪸">
+<!ENTITY rarrlp "↬">
+<!ENTITY ngE "≧̸">
+<!ENTITY nsim "≁">
+<!ENTITY Acy "А">
+<!ENTITY emacr "ē">
+<!ENTITY Jcirc "Ĵ">
+<!ENTITY ltimes "⋉">
+<!ENTITY Bcy "Б">
+<!ENTITY b.Sigma "𝚺">
+<!ENTITY cup "∪">
+<!ENTITY fork "⋔">
+<!ENTITY frac25 "⅖">
+<!ENTITY setmn "∖">
+<!ENTITY bsol "\">
+<!ENTITY Ycy "Ы">
+<!ENTITY b.Phi "𝚽">
+<!ENTITY Gcedil "Ģ">
+<!ENTITY frac23 "⅔">
+<!ENTITY Iogon "Į">
+<!ENTITY blank "␣">
+<!ENTITY vprop "∝">
+<!ENTITY boxVR "╠">
+<!ENTITY ecy "э">
+<!ENTITY OHacgr "Ώ">
+<!ENTITY yen "¥">
+<!ENTITY hairsp " ">
+<!ENTITY plusdo "∔">
+<!ENTITY lvnE "≨︀">
+<!ENTITY boxUr "╙">
+<!ENTITY breve "˘">
+<!ENTITY rtimes "⋊">
+<!ENTITY gnap "⪊">
+<!ENTITY rtrie "⊵">
+<!ENTITY Mcy "М">
+<!ENTITY chi "χ">
+<!ENTITY tdot " ⃛">
+<!ENTITY PSgr "Ψ">
+<!ENTITY Umacr "Ū">
+<!ENTITY caret "⁁">
+<!ENTITY xutri "△">
+<!ENTITY CHcy "Ч">
+<!ENTITY djcy "ђ">
+<!ENTITY lambda "λ">
+<!ENTITY Tstrok "Ŧ">
+<!ENTITY puncsp " ">
+<!ENTITY Ll "⋘">
+<!ENTITY aacgr "ά">
+<!ENTITY xdtri "▽">
+<!ENTITY GJcy "Ѓ">
+<!ENTITY gdot "ġ">
+<!ENTITY sub "⊂">
+<!ENTITY mid "∣">
+<!ENTITY dzcy "џ">
+<!ENTITY igrave "ì">
+<!ENTITY Emacr "Ē">
+<!ENTITY Rcedil "Ŗ">
+<!ENTITY gt ">">
+<!ENTITY harr "↔">
+<!ENTITY larrlp "↫">
+<!ENTITY thgr "θ">
+<!ENTITY drarr "↘">
+<!ENTITY map "↦">
+<!ENTITY boxVh "╫">
+<!ENTITY ijlig "ij">
+<!ENTITY tcedil "ţ">
+<!ENTITY dlcrop "⌍">
+<!ENTITY prnsim "⋨">
+<!ENTITY ecir "≖">
+<!ENTITY rgr "ρ">
+<!ENTITY deg "°">
+<!ENTITY lap "⪅">
+<!ENTITY KJcy "Ќ">
+<!ENTITY Cdot "Ċ">
+<!ENTITY Uogon "Ų">
+<!ENTITY not "¬">
+<!ENTITY dash "‐">
+<!ENTITY nexist "∄">
+<!ENTITY Lt "≪">
+<!ENTITY b.Upsi "𝚼">
+<!ENTITY Atilde "Ã">
+<!ENTITY edot "ė">
+<!ENTITY Ncedil "Ņ">
+<!ENTITY els "⪕">
+<!ENTITY erDot "≓">
+<!ENTITY boxVl "╢">
+<!ENTITY scy "с">
+<!ENTITY ulcorn "⌜">
+<!ENTITY eacgr "έ">
+<!ENTITY Itilde "Ĩ">
+<!ENTITY Zacute "Ź">
+<!ENTITY xharr "⟷">
+<!ENTITY gl "≷">
+<!ENTITY chcy "ч">
+<!ENTITY Oacute "Ó">
+<!ENTITY itilde "ĩ">
+<!ENTITY Ycirc "Ŷ">
+<!ENTITY nhArr "⇎">
+<!ENTITY Lstrok "Ł">
+<!ENTITY divide "÷">
+<!ENTITY Tcy "Т">
+<!ENTITY Jukcy "Є">
+<!ENTITY Yacute "Ý">
+<!ENTITY boxv "│">
+<!ENTITY hamilt "ℋ">
+<!ENTITY nu "ν">
+<!ENTITY ngt "≯">
+<!ENTITY jsercy "ј">
+<!ENTITY uml "¨">
+<!ENTITY KHgr "Χ">
+<!ENTITY lstrok "ł">
+<!ENTITY nsupE "⫆̸">
+<!ENTITY dtrif "▾">
+<!ENTITY vellip "⋮">
+<!ENTITY rceil "⌉">
+<!ENTITY ell "ℓ">
+<!ENTITY Ecy "Э">
+<!ENTITY Jsercy "Ј">
+<!ENTITY ljcy "љ">
+<!ENTITY Kgr "Κ">
+<!ENTITY ngr "ν">
+<!ENTITY sigmav "ς">
+<!ENTITY Gdot "Ġ">
+<!ENTITY rdquor "”">
+<!ENTITY prnap "⪹">
+<!ENTITY tcy "т">
+<!ENTITY frac12 "½">
+<!ENTITY telrec "⌕">
+<!ENTITY vdash "⊢">
+<!ENTITY Zgr "Ζ">
+<!ENTITY Auml "Ä">
+<!ENTITY Ocirc "Ô">
+<!ENTITY uogon "ų">
+<!ENTITY hArr "⇔">
+<!ENTITY nge "≱">
+<!ENTITY iacute "í">
+<!ENTITY Cacute "Ć">
+<!ENTITY Omacr "Ō">
+<!ENTITY equiv "≡">
+<!ENTITY vltri "⊲">
+<!ENTITY eta "η">
+<!ENTITY SHcy "Ш">
+<!ENTITY lowbar "_">
+<!ENTITY percnt "&#x25;">
+<!ENTITY frac16 "⅙">
+<!ENTITY lrarr2 "⇆">
+<!ENTITY nles "⩽̸">
+<!ENTITY bump "≎">
+<!ENTITY veebar "⊻">
+<!ENTITY Wcirc "Ŵ">
+<!ENTITY frac15 "⅕">
+<!ENTITY bumpe "≏">
+<!ENTITY egrave "è">
+<!ENTITY frac14 "¼">
+<!ENTITY supe "⊇">
+<!ENTITY rfloor "⌋">
+<!ENTITY Dgr "Δ">
+<!ENTITY frac13 "⅓">
+<!ENTITY ge "≥">
+<!ENTITY boxVr "╟">
+<!ENTITY pgr "π">
+<!ENTITY kgreen "ĸ">
+<!ENTITY boxh "─">
+<!ENTITY Lambda "Λ">
+<!ENTITY ugrave "ù">
+<!ENTITY emsp13 " ">
+<!ENTITY becaus "∵">
+<!ENTITY sce "⪰">
+<!ENTITY grave "`">
+<!ENTITY zeta "ζ">
+<!ENTITY b.Theta "𝚯">
+<!ENTITY eth "ð">
+<!ENTITY Ouml "Ö">
+<!ENTITY check "✓">
+<!ENTITY hybull "⁃">
+<!ENTITY Gg "⋙">
+<!ENTITY Ccaron "Č">
+<!ENTITY plus "+">
+<!ENTITY fllig "fl">
+<!ENTITY forall "∀">
+<!ENTITY dcaron "ď">
+<!ENTITY gacute "ǵ">
+<!ENTITY sc "≻">
+<!ENTITY OHgr "Ω">
+<!ENTITY emsp14 " ">
+<!ENTITY hellip "…">
+<!ENTITY lhard "↽">
+<!ENTITY sstarf "⋆">
+<!ENTITY samalg "∐">
+<!ENTITY EEgr "Η">
+<!ENTITY rhov "ϱ">
+<!ENTITY b.epsi "𝛆">
+<!ENTITY lsquo "‘">
+]>
+<book><!--<title>JBoss AS 5 Administration and Configuration Guide</title>-->
 	<bookinfo id="JBoss_Application_Server">
 	<title>JBoss Application Server 5.0.0</title>
 	<subtitle>Administration And Development Guide</subtitle>
@@ -9,7 +986,7 @@
 	<pubdate>Mar 2008</pubdate>
 	<abstract>
 		<para>
-			This book is a guide to the administration and configuration of the JBoss Application Server 5.0.0.
+			This book is a <literal>"Work In Progress"</literal> guide to the administration and configuration of the JBoss Application Server 5.
 		</para>
 	</abstract>
 	<subtitle>Authors</subtitle>
@@ -41,6 +1018,7 @@
 	As a JBoss developer, you will be given a good understanding of the architecture and integration of the standard components to enable you to extend or replace the standard components for your infrastructure needs. We also show you how to obtain the JBoss source code, along with how to build and debug the JBoss server.
 </para>
 </preface>
+	
 	<preface id="About_JBoss"><title>About JBoss</title>
 <para>
 	JBoss, a division of Red Hat, is the global leader in open source middleware software, combining enterprise-class JEMS open source software with the industry&#x2019;s leading services and tools to provide simply a better way to transform your business to Service-Oriented Architecture (SOA).
@@ -167,7 +1145,28 @@
 	</orderedlist>
 </para>
 </preface>
+	<section id="Book-We_Need_Feedback">
+	<title>Help Contribute</title>
+	<para>
+		If you find a typographical error in the <citetitle>Administration and Configuration Guide</citetitle>, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in JIRA: <ulink url="http://jira.jboss.com">http://jira.jboss.com</ulink> against the project <citetitle>JBoss Application Server</citetitle> and component <citetitle>Documentation</citetitle>.
+	</para>
+	<para>
+		If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.
+	</para>
+	<note><title>Note</title><para>Be sure to give us your name so you can receive full credit.</para></note>
 	
+	<note><title>Note</title><para>This content is taken from svn.jboss.org/repos/jbossas/projects/docs/trunk and has yet to be branched.</para></note>
+	
+	<para>To access the content directly and make changes yourself:</para>
+<screen>svn co https://svn.jboss.org/repos/jbossas/projects/docs/trunk/AS_5/Administration_And_Configuration_Guide/ --username yourname
+	</screen>
+	
+	<para>The directory structure includes other languages the book will be translated in. For English please edit the files under <emphasis>en-US</emphasis>.
+	</para>
+	<para>To identify the filename you wish to edit, please check the chapter title which will match the file's name. The files are written in Docbook xml. After saving your changes please validate the files you've edited for error's before committing your changes.
+	</para>
+	
+</section>
 	<chapter id="JBoss_AS5_Introduction">
 	<title>Introduction</title>
 	<para>
@@ -175,6 +1174,9 @@
 		The JBoss Microcontainer is a lightweight container that supports direct deployment, configuration and lifecycle of plain old Java objects (POJOs).
 		The JBoss Microcontainer project is standalone and replaces the JBoss JMX Microkernel used in the 3.x and 4.x JBoss Application Servers.
 		Project goals include:
+	</para>
+	
+	<para>
 	<itemizedlist>
 		<listitem>
 			<para>
@@ -202,7 +1204,7 @@
 			</para>
 		</listitem>
 	</itemizedlist>
-		 
+	 
 		The JBoss Microcontainer integrates nicely with the JBoss Aspect
 		Oriented Programming framework (JBoss AOP). JBoss AOP is discussed in <xref linkend="jboss_aop"/> Support for JMX in JBoss AS 5 remains strong and MBean services written against the old Microkernel are expected to work.
 	</para>
@@ -215,6 +1217,7 @@
 	
 	<para>
 		A sample Java EE 5 application that can be run on top of JBoss 5.0.0.Beta4 and above which demonstrates many interesting technologies is the Seam Booking Application available on <ulink url="http://seam.demo.jboss.com/home.seam"/>. This application makes use of the following technologies running on JBoss AS5:
+		
 	<itemizedlist>
 		<listitem>
 			<para>EJB3
@@ -257,48 +1260,47 @@
 		</listitem>
 	</itemizedlist>
 		
-
 	</para>
 	
 	<para>
 		Many key features of JBoss AS5 are provided by integrating other standalone JBoss projects which include: -
 	<itemizedlist>
-		<listitem>
-			<para>
-		JBoss EJB3 included with JBoss 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss AS 4.x series.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBossCache 2.0 that comes in two flavors. A traditional tree-structured node-based cache and a PojoCache, an in-memory, transactional, and replicated cache system that allows users to operate on simple POJOs transparently without active user management of either replication or persistency aspects.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBossWS 2 is the web services stack for JBoss 5 providing Java EE compatible web services, JAXWS-2.0.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBoss Transactions is the default transaction manager for JBoss 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
-			</para>
-		</listitem>
-		<listitem>
-			<para>
-		JBoss Web is the Web container in JBoss 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
-			</para>
-		</listitem>
-	</itemizedlist>
+	<listitem>
+		<para>
+			JBoss EJB3 included with JBoss 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss AS 4.x series.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBossCache 2.0 that comes in two flavors. A traditional tree-structured node-based cache and a PojoCache, an in-memory, transactional, and replicated cache system that allows users to operate on simple POJOs transparently without active user management of either replication or persistency aspects.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBossWS 2 is the web services stack for JBoss 5 providing Java EE compatible web services, JAXWS-2.0.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBoss Transactions is the default transaction manager for JBoss 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			JBoss Web is the Web container in JBoss 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.
+		</para>
+	</listitem>
+</itemizedlist>
 	
 	JBoss AS5 includes numerous features and bug fixes, many of them carried over upstream from the JBoss AS4.x codebase. See the Detailed Release Notes section for the full details.
-	</para>
+</para>
 	
-	<section><title>JBoss Application Server use cases</title>
+<section><title>JBoss Application Server use cases</title>
 		<para>
 			<itemizedlist>
 				<listitem>
@@ -392,15 +1394,35 @@
 	</itemizedlist>
 	</para>
 	
-	</section>
-		
+	
 	<para>
-		More information about JBoss Enterprise Application Platform and Enterprise middleware can be obtained on <ulink url="http://www.jboss.com/products/index"/> and <ulink url="http://www.redhat.com/promo/migration/"/>. 
+		More information about JBoss Enterprise Application Platform and Enterprise middleware can be obtained on <ulink url="http://www.jboss.com/products/index"/> and <ulink url="http://www.redhat.com/promo/migration/"/>
 	</para>
 	
 	</section>
+		
 	
+	
+</section>
+	
 		
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 	<section>
 		<title>JBoss Application Server 5 compatibility issues</title>
 		<para>
@@ -462,6 +1484,7 @@
 	
 	</para>
 </section>
+
 </chapter>
 
 	
@@ -470,14 +1493,15 @@
 		
 		<chapter id="JBoss_AS5_Architecture">
 	<title>JBoss Application Server 5 architecture</title>
+	<para>
 	The following diagram illustrates an overview of the JBoss.org community projects including the JBoss Appplication Server and its components.
 	<inlinemediaobject>
 		<imageobject>
 			<imagedata fileref="images/projects_communitygraph.png"/>
 		</imageobject>
 	</inlinemediaobject>
+</para>
 	
-	
 	<para>
 		The directory structure of JBoss 5 resembles that of the 4.x series with some notable differences:
 <screen><![CDATA[-&lt;JBOSS_HOME&gt;/ - the path to your JBoss AS installation.
@@ -585,16 +1609,199 @@
 
 <para>JBoss Application Server 5.0 uses the microcontainer to integrate enterprise services together with a Servlet/JSP container, EJB container, deployers and management utilities in order to provide a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. Likewise you are free to remove any services that you don't need simply by changing the configuration. You can even use the microcontainer to do this in other environments such as Tomcat and GlassFish since you can plug in different classloading models during the service deployment phase.</para>
 <para>Since JBoss Microcontainer is very lightweight and deals with POJOs it can also be used to deploy services into a Java ME runtime environment. This opens up new possibilities for mobile applications that can now take advantage of enterprise services without requiring a full JEE application server. </para>
-<para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.</para>
+<para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.
+</para>
+
+<section><title>An overview of the Microcontainer modules</title>
 <para>
-	.....more content coming...
+
+	This section introduces the various Microcontainer modules. The figure below gives an overview of the modules.
+	
+	<inlinemediaobject>
+		<imageobject>
+			<imagedata fileref="images/microcontainer.png"/>
+		</imageobject>
+	</inlinemediaobject>
+	
+	<itemizedlist>
+		<listitem>
+			<para>	
+				<literal>aop-mc-int</literal> handles integration between the JBossAOP and Microcontainer projects
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				The <literal>container</literal> module contains: reflection, the integration point for manipulating class information at runtime, e.g. overriding annotations or obtaining an aop instance advisor. joinpoint, the joinpoint model including the join point factory. classadaptor, the integration and configuration spi. metadata, base metadata types and repository
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>dependency</literal> management is handled by the controller. The controller is the core component for keeping track of contexts to make sure the configuration and lifecycle are done in the correct order including dependencies and classloading considerations.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>deployers</literal> load components from various models, POJOs, JMX, spring, Java EE, etc. into the Microcontainer runtime.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>kernel</literal> kernel defines the core kernel spi including, boostrap, configuration, POJO deployments, dependency, events, bean metadata, and bean registry.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				The <literal>managed</literal> module defines the base objects defining the management view of a component.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				The <literal>metatype</literal> metatype module defines the base types found in the management view of a component.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>osgi-int</literal> contains the integration classes that adapt the OSGi model onto the Microcontainer.
+			</para>
+		</listitem>
+		<listitem>
+			<para>	
+				<literal>spring-int</literal> contains the integration classes that adapt the spring model onto the Microcontainer. 
+			</para>
+		</listitem>
+	</itemizedlist>
+	
+			</para>
+</section>
+
+<section><title>Configuration</title>
+	<para>To configure your microcontainer the you can use the  <emphasis>JBOSS_HOME/server/&lt;server_configuration&gt;/conf/bootstrap-beans.xml</emphasis> and <emphasis>JBOSS_HOME/server/&lt;server_configuration&gt;/conf/bootstrap-repo-beans.xml</emphasis> files where <emphasis>&lt;server_configuration&gt;</emphasis> represents the <emphasis>all</emphasis>, <emphasis>default</emphasis> or <emphasis>minimal</emphasis> JBoss AS configurations. The configuration files have comments to guide you on the specific configurations available as illustrated by the example below. 
+	</para>
+<programlisting role="XML">
+	&lt;deployment xmlns="urn:jboss:bean-deployer:2.0"&gt;
+		
+		&lt;!-- All beans use the bootstrap classloader --&gt;
+		&lt;classloader&gt;&lt;inject bean="BootstrapClassLoader"/&gt;&lt;/classloader&gt;
+		
+		&lt;!-- TODO Should split this file up and use the new classloader --&gt;
+		&lt;bean name="BootstrapClassLoader" class="org.jboss.system.NoAnnotationURLClassLoader"&gt;
+		&lt;classloader&gt;&lt;null/&gt;&lt;/classloader&gt;
+			&lt;constructor factoryClass="org.jboss.system.NoAnnotationURLClassLoader" factoryMethod="createClassLoader"&gt;
+		&lt;parameter&gt;
+.....
+......
+&lt;bean name="ProfileServiceBootstrap" class="org.jboss.system.server.profileservice.ProfileServiceBootstrap"&gt;
+&lt;property name="kernel"&gt;&lt;inject bean="jboss.kernel:service=Kernel"/&gt;&lt;/property&gt;
+&lt;/bean&gt;
+
+&lt;!-- The legacy JMX kernel --&gt;
+&lt;bean name="JMXKernel" class="org.jboss.system.server.jmx.JMXKernel"&gt;
+&lt;property name="kernel"&gt;&lt;inject bean="jboss.kernel:service=Kernel"/&gt;&lt;/property&gt;
+	&lt;property name="serverImpl"&gt;&lt;inject bean="JBossServer"/&gt;&lt;/property&gt;
+	&lt;property name="oldClassLoader"&gt;false&lt;/property&gt;
+&lt;/bean&gt;
+....(content truncated)
+......
+
+	&lt;!-- The ManagedDeploymentCreator implementation --&gt;
+	&lt;bean name="ManagedDeploymentCreator" 	class="org.jboss.deployers.plugins.managed.DefaultManagedDeploymentCreator" /&gt;
+   
+	&lt;!-- The holder for deployers that determine structure --&gt;
+	&lt;bean name="StructuralDeployers" 		class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl"&gt;
+		&lt;property name="structureBuilder"&gt;
+		&lt;!-- The consolidator of the structure information --&gt;
+		&lt;bean name="StructureBuilder" 		class="org.jboss.deployers.vfs.plugins.structure.VFSStructureBuilder"/&gt;
+	&lt;/property&gt;
+	&lt;!-- Accept any implementor of structure deployer --&gt;
+	&lt;incallback method="addDeployer"/&gt;
+	&lt;uncallback method="removeDeployer"/&gt;
+&lt;/bean&gt;
+...(content truncated)
+...
+</programlisting>
+
+<para>The main beans are:
+	<itemizedlist>
+		<listitem>
+			<para><emphasis>ProfileService</emphasis> : this bean loads the deployments associated with the named server profile, "default", "all" or whatever name is passed in as the "-c" option to the server. Its an extension of the jboss-4.0.x and earlier notion of always looking to the filesystem <literal>server/name/conf/jboss-service.xml</literal> and <literal>server/name/deploy</literal> to load deployments.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>AspectManager?</emphasis> : the AOP aspects
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>MainDeployer</emphasis> : this bean is an update of the JMX based MainDeployer from earlier versions to a one based on the Microcontainer, JBoss5VirtualFileSystem, and Virtual Deployment Framework(VDF). Deployer aspects are registered with the MainDeployer as an ordered list via inject of the deployers property.
+		</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>ServiceClassLoaderDeployer?</emphasis> : this bean manages the class loading aspect of deployment.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>JARDeployer</emphasis> : this bean is a structural deployment aspect which handles the legacy nested deployment behavior of adding non-deployable jars to the current deployment classpath.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>FileStructure?</emphasis> : this bean is a structural deployment aspect which recognizes well know deployment file types specified by suffix.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>AspectDeployer?</emphasis> : handles aop descriptor deployments.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>BeanDeployer?</emphasis> : this bean translates deployer-beans.xml into KernelDeployment? for the descriptor beans.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>KernelDeploymentDeployer?</emphasis> : translates a KernelDeployment? into the constituent BeanMetaData instances for the kernel beans.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>BeanMetaDataDeployer?</emphasis> : creates the kernel beans from the deployment BeanMetaData.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>SARDeployer</emphasis> : this bean is a port of the legacy JMX SARDeployer to the VDF. It handles the legacy jboss-service.xml style of mbean deployment descriptors and maps this into a ServiceDeployment? pojo.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>ServiceDeploymentDeployer?</emphasis> : translates ServiceDeployment? pojo into the constituent ServiceMetaData that represent the various mbeans.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>ServiceDeployer?</emphasis> : creates the mbean services from deployment ServiceMetaData instances.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>JMXKernel</emphasis> : this bean manages the instantiation of a JMX kernel and MBeanServer in the jboss domain. It is used by the SARDeployer. It will be used by other management deployment aspects in the future to expose kernel beans via JMX.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>VFSDeployerScanner?</emphasis> : a scanner bean that loads the deployers directory contents into the basic profile service.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>VFSDeploymentScanner?</emphasis> : a scanner bean that loads the deploy directory contents into the basic profile service.
+			</para>
+		</listitem>
+		<listitem>
+			<para><emphasis>HDScanner</emphasis> : a bean that queries the profile service for changes in deploy directory contents and redeploys updated content, undeploys removed content, and add new deployment content to the profile service.
+			</para>
+		</listitem>
+	</itemizedlist>
+
 </para>
 
-<section>
-	<title>References</title>
-<para>More information on the JBoss Microcontainer project can be obtained from <ulink url="http://labs.jboss.com/jbossmc/"/> </para>.
 </section>
 
+
+
+<section><title>References</title>
+<para>More information on the JBoss Microcontainer project can be obtained from <ulink url="http://labs.jboss.com/jbossmc/"/>. </para>
+</section>
+
 </chapter>
 		<chapter id="Web_Services">
 	<title>Web Services</title>
@@ -612,7 +1819,7 @@
 		JBossWS integrates with most current JBoss Application Server releases as well as earlier ones, that did implement the J2EE 1.4 specifications. Even though JAX-RPC, the web service specification for J2EE 1.4, is still supported JBossWS does put a clear focus on JAX-WS. 
 	</para>
 	<section><title>Who needs web services?</title> 
-		<para>
+	<para>
 		Enterprise systems communication may benefit from a wise adoption of WS technologies. Exposing well designed contracts allows developers to extract an abstract view of their service capabilities. Considering the standardized way contracts are written, this definitely helps communication with third-party systems and eventually support business-to-business integration. No more agreement required on vendor specific implementation details, home-brew communication protocol or custom per-customer settings. Everything is clear and standardized in the contract the provider and consumer agree on. Of course this also reduces the dependencies between implementations allowing other consumers to easily use the provided service without major changes. 
 	</para>
 	<para>
@@ -792,12 +1999,13 @@
 
 
 	
-	<section><title>The MTOM enabled SOAP 1.1 binding ID</title> 
+<section><title>The MTOM enabled SOAP 1.1 binding ID</title> 
+<para>
+	MTOM enabled clients
+</para> 
 	<para>
-	MTOM enabled clients</para> 
-	<para>
 	Web service clients can use the same approach described above or rely on the Binding API to enable MTOM (Excerpt taken from the <literal>org.jboss.test.ws.jaxws.samples.xop.doclit.XOPTestCase</literal>): 
-</para>
+	</para>
 
 <programlisting role="JAVA">[...] 
 	Service service = Service.create(wsdlURL, serviceName); 
@@ -810,14 +2018,14 @@
 
 </section>
 
-<para>	to do list</para>
-<para>- JBoss Web Services 2.0.3.GA</para> 
-<para>- Attachment Support with XOP and SwA</para> 
+<!--<para>	to do list</para>
+<para>- JBoss Web Services 2.0.3.GA</para>
+<para>- Attachment Support with XOP and SwA</para>
 <para>- JMS Transport </para>
-<para>- WS-Addressing</para> 
+<para>- WS-Addressing</para>
 <para>- WS-Security </para>
 <para>- WS-Policy </para>
-<para>- WS-Eventing</para>
+<para>- WS-Eventing</para>-->
 
 </section>
 	
@@ -4007,12 +5215,13 @@
 <formalpara><title>Interceptor</title>
 <para>An interceptor is an Aspect with only one advice named "invoke". It is a specific interface that you can implement if you want your code to be checked by forcing your class to implement an interface. It also will be portable and can be reused in other JBoss environments like EJBs and JMX MBeans. </para>
 </formalpara>
-</section>
 
+<!--merged sections</section>-->
+
 <para>In AOP, a feature like metrics is called a <emphasis>crosscutting concern</emphasis>, as it's a behavior that "cuts" across multiple points in your object models, yet is distinctly different. As a development methodology, AOP recommends that you abstract and encapsulate crosscutting concerns.</para>
 <para>For example, let's say you wanted to add code to an application to measure the amount of time it would take to invoke a particular method. In plain Java, the code would look something like the following. </para>
-<para>
-<programlisting><![CDATA[public class BankAccountDAO
+
+<programlisting role="JAVA">public class BankAccountDAO
 {
  public void withdraw(double amount)
  {
@@ -4027,9 +5236,10 @@
    System.out.println("withdraw took: " + endTime);
   }
  }
-}]]></programlisting>
-</para>
+}</programlisting>
+
 <para>While this code works, there are a few problems with this approach:
+
 <orderedlist>
 <listitem>
 <para>It's extremely difficult to turn metrics on and off, as you have to manually add the code in the <emphasis>try&gt;/finally</emphasis> block to each and every method or constructor you want to benchmark. </para>
@@ -4038,14 +5248,20 @@
 <para>The profiling code really doesn't belong sprinkled throughout your application code. It makes your code bloated and harder to read, as you have to enclose the timings within a try/finally block. </para>
 </listitem>
 <listitem>
-<para>If you wanted to expand this functionality to include a method or failure count, or even to register these statistics to a more sophisticated reporting mechanism, you'd have to modify a lot of different files (again). </para>
+<para>If you wanted to expand this functionality to include a method or failure count, or even to register these statistics to a more sophisticated reporting mechanism, you'd have to modify a lot of different files (again).</para>
 </listitem>
 </orderedlist>
 </para>
-<para>This approach to metrics is very difficult to maintain, expand, and extend, because it's dispersed throughout your entire code base. And this is just a tiny example! In many cases, OOP may not always be the best way to add metrics to a class. </para>
 
-<para>Aspect-oriented programming gives you a way to encapsulate this type of behavior functionality. It allows you to add behavior such as metrics "around" your code. For example, AOP provides you with programmatic control to specify that you want calls to BankAccountDAO to go through a metrics aspect before executing the actual body of that code. </para>
+<para>
+	This approach to metrics is very difficult to maintain, expand, and extend, because it's dispersed throughout your entire code base. And this is just a tiny example! In many cases, OOP may not always be the best way to add metrics to a class.
+</para>
 
+<para>
+	Aspect-oriented programming gives you a way to encapsulate this type of behavior functionality. It allows you to add behavior such as metrics "around" your code. For example, AOP provides you with programmatic control to specify that you want calls to BankAccountDAO to go through a metrics aspect before executing the actual body of that code.
+</para>
+</section>
+
 <section>
 	<title>Creating Aspects in JBoss AOP</title>
 	<para>
@@ -4056,8 +5272,9 @@
 		The first step in creating a metrics aspect in JBoss AOP is to encapsulate the metrics feature in its own Java class. Listing Two extracts the try/finally block in Listing One's BankAccountDAO.withdraw() method into Metrics, an implementation of a JBoss AOP Interceptor class.
 	</para>
 	<para>
-The following listing demonstrates Implementing metrics in a JBoss AOP Interceptor
-<programlisting><![CDATA[01. public class Metrics implements org.jboss.aop.advice.Interceptor
+		The following listing demonstrates Implementing metrics in a JBoss AOP Interceptor
+	</para>
+<programlisting role="JAVA">01. public class Metrics implements org.jboss.aop.advice.Interceptor
 02. {
 03.   public Object invoke(Invocation invocation) throws Throwable
 04.   {
@@ -4073,9 +5290,8 @@
 14.       System.out.println("method " + m.toString() + " time: " + endTime + "ms");
 15.     }
 16.   }
-17. }]]></programlisting>	
+17. }</programlisting>	
 
-	</para>
 	<para>
 		Under JBoss AOP, the Metrics class wraps withdraw(): when calling code invokes withdraw(), the AOP framework breaks the method call into its parts and encapsulates those parts into an Invocation object. The framework then calls any aspects that sit between the calling code and the actual method body.
 	</para>
@@ -4083,29 +5299,31 @@
 		When the AOP framework is done dissecting the method call, it calls Metric's invoke method at line 3. Line 8 wraps and delegates to the actual method and uses an enclosing try/finally block to perform the timings. Line 13 obtains contextual information about the method call from the Invocation object, while line 14 displays the method name and the calculated metrics.
 	</para>
 	<para>
-	Having the metrics code within its own object allows us to easily expand and capture additional measurements later on. Now that metrics are encapsulated into an aspect, let's see how to apply it.
+		Having the metrics code within its own object allows us to easily expand and capture additional measurements later on. Now that metrics are encapsulated into an aspect, let's see how to apply it.
 	</para>
 	
 </section>
 	
 <section>
 	<title>Applying Aspects in JBoss AOP</title>
-	<para>To apply an aspect, you define when to execute the aspect code. Those points in execution are called pointcuts. An analogy to a pointcut is a regular expression. Where a regular expression matches strings, a pointcut expression matches events/points within your application. For example, a valid pointcut definition would be "for all calls to the JDBC method executeQuery(), call the aspect that verifies SQL syntax." 
+	<para>
+		To apply an aspect, you define when to execute the aspect code. Those points in execution are called pointcuts. An analogy to a pointcut is a regular expression. Where a regular expression matches strings, a pointcut expression matches events/points within your application. For example, a valid pointcut definition would be "for all calls to the JDBC method executeQuery(), call the aspect that verifies SQL syntax." 
 	</para>
 	<para>
 		An entry point could be a field access, or a method or constructor call. An event could be an exception being thrown. Some AOP implementations use languages akin to queries to specify pointcuts. Others use tags. JBoss AOP uses both. Listing Three shows how to define a pointcut for the metrics example.
 	</para>
 	<para>
-	The following listing demonstrates defining a pointcut in JBoss AOP
-<programlisting><![CDATA[1. <bind pointcut="public void com.mc.BankAccountDAO->withdraw(double amount)">
-2.       <interceptor class="com.mc.Metrics"/>
-3. </bind >
+		The following listing demonstrates defining a pointcut in JBoss AOP
+	</para>
+<programlisting role="XML">1. &lt;bind pointcut="public void com.mc.BankAccountDAO-&gt;withdraw(double amount)"&gt;
+2.       &lt;interceptor class="com.mc.Metrics"/&gt;
+3. &lt;/bind &gt;
 	
-4. <bind pointcut="* com.mc.billing.*->*(..)">
-5.       <interceptor class="com.mc.Metrics"/>
-6. </bind >]]></programlisting>
+4. &lt;bind pointcut="* com.mc.billing.*-&gt;*(..)"&gt;
+5.       &lt;interceptor class="com.mc.Metrics"/&gt;
+6. &lt;/bind &gt;]]&gt;&lt;/programlisting&gt;
+</programlisting>
 
-</para>
 <para>
 	Lines 1-3 define a pointcut that applies the metrics aspect to the specific method BankAccountDAO.withdraw(). Lines 4-6 define a general pointcut that applies the metrics aspect to all methods in all classes in the com.mc.billing package. 
 	There is also an optional annotation mapping if you do not like XML. See our Reference Guide for more information. 
@@ -4120,7 +5338,7 @@
 	Notice too that the code within the BankAccountDAO class has no idea that it's being profiled. This is what aspect-oriented programmers deem orthogonal concerns. Profiling is an orthogonal concern. In the OOP code snippet in Listing One, profiling was part of the application code. With AOP, you can remove that code. A modern promise of middleware is transparency, and AOP (pardon the pun) clearly delivers. 
 </para>
 <para>
-Just as important, orthogonal behavior could be bolted on after development. In Listing One, monitoring and profiling must be added at development time. With AOP, a developer or an administrator can (easily) add monitoring and metrics as needed without touching the code. This is a very subtle but significant part of AOP, as this separation (obliviousness, some may say) allows aspects to be layered on top of or below the code that they cut across. A layered design allows features to be added or removed at will. For instance, perhaps you snap on metrics only when you're doing some benchmarks, but remove it for production. With AOP, this can be done without editing, recompiling, or repackaging the code. 
+	Just as important, orthogonal behavior could be bolted on after development. In Listing One, monitoring and profiling must be added at development time. With AOP, a developer or an administrator can (easily) add monitoring and metrics as needed without touching the code. This is a very subtle but significant part of AOP, as this separation (obliviousness, some may say) allows aspects to be layered on top of or below the code that they cut across. A layered design allows features to be added or removed at will. For instance, perhaps you snap on metrics only when you're doing some benchmarks, but remove it for production. With AOP, this can be done without editing, recompiling, or repackaging the code. 
 </para>
 </section>
 </chapter>
@@ -4146,6 +5364,7 @@
 		</listitem>
 	</orderedlist>
 	<para>Pojo Cache has a complete and separate set of documentation, including a user guide, FAQ and tutorial and as such, Pojo Cache is not discussed further in this book. </para>
+	<para>Pojo Cache deployment in the JBoss AS5 is discussed more in <xref linkend="pojocachedeployment"/></para>	
 </section>
 <section><title>Summary of Features</title>
 	<para>JBoss Cache offers a simple and straightforward API, where data (simple Java objects) can be placed in the cache and, based on configuration options selected, this data may be one or all of: </para>
@@ -4179,65 +5398,16 @@
 	<para>JBoss Cache works out of the box with most popular transaction managers, and even provides an API where custom transaction manager lookups can be written. </para>
 	<para>The cache is also completely thread-safe. It uses a pessimistic locking scheme for nodes in the tree by default, with an optimistic locking scheme as a configurable option. With pessimistic locking, the degree of concurrency can be tuned using a number of isolation levels, corresponding to database-style transaction isolation levels, i.e., SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED and NONE. Concurrency, locking and isolation levels will be discussed later. </para>
 </section>
-<section>
-	<title>JGroups </title>
-	<para>JGroups is a toolkit for reliable multicast communication. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.</para>
-	<para/>
-	<orderedlist>
-		<listitem>
-			<para>Group creation and deletion. Group members can be spread across LANs or WANs </para>
-		</listitem>
-		<listitem>
-			<para>Joining and leaving of groups </para>
-		</listitem>
-		<listitem>
-			<para>Membership detection and notification about joined/left/crashed members </para>
-		</listitem>
-		<listitem>
-			<para>Detection and removal of crashed members </para>
-		</listitem>
-		<listitem>
-			<para>Sending and receiving of member-to-group messages (point-to-multipoint) </para>
-		</listitem>
-		<listitem>
-			<para>Sending and receiving of member-to-member messages (point-to-point) </para>
-		</listitem>
-	</orderedlist>
-</section>
-	<section>
-		<title>Flexible Protocol Stack</title>
-	<para>The most powerful feature of JGroups is its flexible protocol stack, which allows developers to adapt it to exactly match their application requirements and network characteristics. The benefit of this is that you only pay for what you use. By mixing and matching protocols, various differing application requirements can be satisfied. JGroups comes with a number of protocols (but anyone can write their own), for example </para>
-	<para>
-	<orderedlist>
-		<listitem>
-			<para>Transport protocols: UDP (IP Multicast), TCP, JMS </para>
-		</listitem>
-		<listitem>
-			<para>Fragmentation of large messages </para>
-		</listitem>
-		<listitem>
-			<para>Reliable unicast and multicast message transmission. Lost messages are retransmitted </para>
-		</listitem>
-		<listitem>
-			<para>Failure detection: crashed members are excluded from the membership </para>
-		</listitem>
-		<listitem>
-			<para>Ordering protocols: Atomic (all-or-none message delivery), Fifo, Causal, Total Order (sequencer or token based) </para>
-		</listitem>
-		<listitem>
-			<para>Membership </para>
-		</listitem>
-		<listitem>
-			<para>Encryption </para>
-		</listitem>
-	</orderedlist>
-</para>
-</section>
 
+
 <section>
 	<title>Running JBoss Cache in the JBoss Application server</title>
-	<para>The following is the JBoss Cache JGroups and JBoss Application Server compatibility matrix.</para>
 	<para>
+		JBoss Cache uses JGroups as a transport layer. More information on JGroups can be found on <xref linkend="jgroups"/>
+	</para>
+	
+	<!--<para>The following is the JBoss Cache JGroups and JBoss Application Server compatibility matrix.</para>
+	<para>
 		<table frame="all"><title>JBoss Application Server + JBoss Cache</title>
 		<tgroup cols="3"><tbody>
 				<row>
@@ -4259,7 +5429,7 @@
 						<para>1.2 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4270,7 +5440,7 @@
 						<para>1.2.2 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4281,7 +5451,7 @@
 						<para>1.2 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4360,16 +5530,17 @@
 							<emphasis>2.1.0</emphasis> </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row></tbody></tgroup>
 	</table>
-<note><title/><para>For JBoss AS 4.0.3SP1 (and earlier) to run with JBoss Cache 1.4.0.x you need to add jboss-serialization.jar to JBOSS_HOME/server/all/lib </para></note>
+<note><title></title><para>For JBoss AS 4.0.3SP1 (and earlier) to run with JBoss Cache 1.4.0.x you need to add jboss-serialization.jar to JBOSS_HOME/server/all/lib </para></note>
 
-<note><title/><para>Upgrading to these JBoss Cache versions within JBoss AS 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>
+<note><title></title><para>Upgrading to these JBoss Cache versions within JBoss AS 4.0.x requires JGroups to be upgraded to 2.2.9 or higher</para></note>-->
 	
 
 <para>	
+	<!--
 	<table frame="all"><title>JBoss Application Server + Jgroups compatibility matrix</title>
 		<tgroup cols="3"><tbody>
 				<row>
@@ -4391,7 +5562,7 @@
 						<para>2.2.0 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4402,7 +5573,7 @@
 						<para>2.2.0 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4413,7 +5584,7 @@
 						<para>2.2.4 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4424,7 +5595,7 @@
 						<para>2.2.4 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4435,7 +5606,7 @@
 						<para>2.2.5 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4556,7 +5727,7 @@
 						<para>2.4.1.SP1 </para>
 					</entry>
 					<entry>
-						<para>&#xA0; </para>
+						<para>  </para>
 					</entry>
 				</row>
 				<row>
@@ -4567,7 +5738,7 @@
 						<para>2.4.1.SP3 </para>
 					</entry>
 					<entry>
-						<para>&#xA0; </para>
+						<para>  </para>
 					</entry>
 				</row>
 				<row>
@@ -4584,11 +5755,11 @@
 						<para/>
 					</entry>
 				</row></tbody></tgroup>
-	</table>
+	</table>-->
 </para>
 
-	
-	<table frame="all"><title>JBoss Cache + Jgroups compatibility matrix</title>
+<para>	
+	<!--<table frame="all"><title>JBoss Cache + Jgroups compatibility matrix</title>
 		<tgroup cols="3"><tbody>
 				<row>
 					<entry>
@@ -4609,7 +5780,7 @@
 						<para>2.2.1 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4620,7 +5791,7 @@
 						<para>2.2.3 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4631,7 +5802,7 @@
 						<para>2.2.6 </para>
 					</entry>
 					<entry>
-						<para>&#xA0;</para>
+						<para> </para>
 					</entry>
 				</row>
 				<row>
@@ -4745,7 +5916,7 @@
 						<para/>
 					</entry>
 				</row></tbody></tgroup>
-	</table>
+	</table>-->
 </para>
 
 	<para>In the JBoss Application Server 5, JBoss cache runs in the <emphasis>all</emphasis> configuration of the application server(i.e &lt;JBOSS_HOME&gt;/server/all). All you need to do is start the server with this configuration.
@@ -4774,6 +5945,104 @@
 	<para>Once the proxy to the CacheJmxWrapper is obtained, the getCache() will return a reference to the Cache itself. </para>
 </section>
 
+<section id="pojocachedeployment"><title>Pojo Cache Deployment Options</title>
+	<para>
+		There are a number of ways to deploy POJO Cache:
+	</para>
+	<section><title>Programatic Deployment</title>
+		<para>
+		Simply instantiate a PojoCacheFactory and invoke one of the overloaded createCache methods shown in the API Overview.
+		</para>
+	</section>
+	<section><title>JMX-Based Deployment in JBoss AS (JBoss AS 5.x and 4.x)</title>
+		<para>
+		If PojoCache is run in JBoss AS then your cache can be deployed as an MBean simply by copying a standard cache configuration file to the server's deploy directory. The standard format of PojoCache's standard XML configuration file (as shown in the Appendix) is the same as a JBoss AS MBean deployment descriptor, so the AS's SAR Deployer has no trouble handling it. Also, you don't have to place the configuration file directly in deploy; you can package it along with other services or JEE components in a SAR or EAR.
+		</para>
+		<para>
+		In AS 5, if you're using a server config based on the standard all config, then that's all you need to do; all required jars will be on the classpath. Otherwise, you will need to ensure pojocache.jar, jbosscache.jar and jgroups-all.jar are on the classpath. You may need to add other jars if you're using things like JdbmCacheLoader. The simplest way to do this is to copy the jars from the PojoCache distribution's lib directory to the server config's lib directory. You could also package the jars with the configuration file in Service Archive (.sar) file or an EAR.
+		</para>
+		<para>
+		It is possible, to deploy a POJO Cache 2.0 instance in JBoss AS 4.x However, the significant API changes between the 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on the 1.x API will work with PojoCache 2.x. Also, be aware that usage of PojoCache 2.x in AS 4.x is not something the cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)
+		</para>
+		<para>
+		Note in the example the value of the mbean element's code attribute: org.jboss.cache.pojo.jmx.PojoCacheJmxWrapper. This is the class JBoss Cache uses to handle JMX integration; the PojoCache itself does not expose an MBean interface. See the JBoss Cache MBeans section for more on the PojoCacheJmxWrapper.
+		</para>
+		<para>
+		Once your cache is deployed, in order to use it with an in-VM client such as a servlet, a JMX proxy can be used to get a reference to the cache:
+		</para>
+<programlisting role="JAVA">MBeanServer server = MBeanServerLocator.locateJBoss();
+		
+	ObjectName on = new ObjectName("jboss.cache:service=PojoCache");
+	
+	PojoCacheJmxWrapperMBean cacheWrapper =
+	
+	(PojoCacheJmxWrapperMBean) MBeanServerInvocationHandler.newProxyInstance(server, on,
+		
+	PojoCacheJmxWrapperMBean.class, false);
+		
+	PojoCache cache = cacheWrapper.getPojoCache();</programlisting>		
+		
+	<para>	
+		The MBeanServerLocator class is a helper to find the (only) JBoss MBean server inside the current JVM. The javax.management.MBeanServerInvocationHandler class' newProxyInstance method creates a dynamic proxy implementing the given interface and uses JMX to dynamically dispatch methods invoked against the generated interface to the MBean. The name used to look up the MBean is the same as defined in the cache's configuration file.
+	</para>
+	<para>
+		Once the proxy to the PojoCacheJmxWrapper is obtained, the getPojoCache() will return a reference to the PojoCache itself.
+	</para>
+</section>
+<section><title>Via JBoss Microcontainer (JBoss AS 5.x)</title>
+		<para>
+		Beginning with AS 5, JBoss AS also supports deployment of POJO services via deployment of a file whose name ends with -beans.xml. A POJO service is one whose implementation is via a "Plain Old Java Object", meaning a simple java bean that isn't required to implement any special interfaces or extend any particular superclass. A PojoCache is a POJO service, and all the components in a Configuration are also POJOS, so deploying a cache in this way is a natural step.
+	</para>
+	<para>
+		Deployment of the cache is done using the JBoss Microcontainer that forms the core of JBoss AS. JBoss Microcontainer is a sophisticated IOC framework (similar to Spring). A -beans.xml file is basically a descriptor that tells the IOC framework how to assemble the various beans that make up a POJO service.
+	</para>
+	<para>
+		The rules for how to deploy the file, how to package it, how to ensure the required jars are on the classpath, etc. are the same as for a JMX-based deployment.
+	</para>
+	<para>
+		Following is an abbreviated example -beans.xml file. The details of building up the Configuration are omitted; see the "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for a more complete example. If you look in the <filename>server/all/deploy</filename> directory of an AS 5 installation, you can find several more examples.
+	</para>
+		
+	<programlisting role="XML">&lt;?xml version="1.0" encoding="UTF-8"?&gt;
+&lt;deployment xmlns="urn:jboss:bean-deployer:2.0"&gt;
+		
+	&lt;!-- First we create a Configuration object for the cache --&gt;
+		
+	&lt;bean name="ExampleCacheConfig"
+	
+	class="org.jboss.cache.config.Configuration"&gt;
+		
+	... details omitted
+		
+		
+	&lt;/bean&gt;
+		
+&lt;!-- The cache itself. --&gt;
+		
+&lt;bean name="ExampleCache" class="org.jboss.cache.pojo.impl.PojoCacheImpl"&gt;
+		
+	&lt;constructor factoryClass="org.jboss.cache.pojo.PojoCacheFactory
+		
+		factoryMethod="createCache"&gt;
+		
+	&lt;parameter&gt;&lt;inject bean="ExampleCacheConfig"/&gt;&lt;/parameter&gt;
+		
+	&lt;parameter&gt;false&lt;/false&gt;
+		
+	&lt;/constructor&gt;
+		
+&lt;/bean&gt;
+		
+&lt;/deployment&gt;....</programlisting>			
+	
+	<para>
+		An interesting thing to note in the above example is the difference between POJO Cache and a plain Cache in the use of a factory to create the cache. (See the "Deploying JBoss Cache" chapter in the JBoss Cache User Guide for the comparable plain Cache example.) The PojoCacheFactory exposes static methods for creating a PojoCache; as a result there is no need to add a separate bean element for the factory. Core Cache's DefaultCacheFactory creates caches from a singleton instance, requiring a bit more boilerplate in the config file.
+	</para>
+	</section>
+</section>	
+
+
+
 <section><title>References:</title>
 	<para>
 		More information on JBoss Cache can be obtained from the following resources:
@@ -4790,7 +6059,6 @@
 </chapter>
 		<chapter id="transaction"><title>JBoss Transactions</title>
 
-<para>With over 20 years of expertise in the area of transaction processing, JBoss Transactions (JBossTS) is the premier open source transaction manager. It can be deployed within a range of application servers, containers or run stand-alone. Over the past 20 years it has been used extensively within industry and to drive standards including the OMG and Web Services. </para>
 <para>JBoss Transactions runs in the <emphasis>all</emphasis> server configurations or customized configurations based on the <emphasis>all</emphasis> configuration. </para>
 <para>
 <inlinegraphic fileref="images/transactions-architecture.png" width=""/>
@@ -4804,13 +6072,13 @@
 </section>
 
 
-<section><title>JBoss Transactions J2EE Support</title>
+<section><title>JBoss Transactions Java EE 5 Support</title>
 <para>In the modern business environment of system consolidations, worldwide utilization, and "always- on" availability, enterprises need distributed transaction processing infrastructure to build reliable, sophisticated business applications that can guarantee absolute completion and accuracy of business processes. Transaction services ensure that sequences of database updates have been accurately and reliably committed as a single complete unit of work or that, in the event of failure, the database information is recovered. "Multimodal Transaction Processing" is the term coined by Gartner to describe the new generation of transactional application required to face the challenges posed by new business requirements, technologies and innovative computing architectures. </para>
 <note>
 <para>"Multimodal transaction processing will emerge. Users' adoption of client/server, the Internet, service-oriented architecture, Web services, mobile and wireless devices, and event-driven architectures means that the next generation of transaction processing applications will have to be implemented in very different ways to respond to new business strategies, including multichannel, the real-time enterprise and business process fusion." Predicts 2004: Prepare for Multimodal Transaction Processing, M. Pezzini, Gartner, 19 December 2003 </para></note>
 
 <para>JBossTS is a middleware solution that supports mission-critical applications in distributed computing environments. It plays a critical role in building reliable, sophisticated e-business applications guaranteeing absolute completion and accuracy of business processes. JBossTS supports "multimodal transaction processing" by enabling reliable transactions to span from front-end e-commerce applications to back office systems and beyond the enterprise firewall to business partners - across any system, anywhere in the world. </para>
-<para>Building on the industry proven J2EE transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The product supports the WS-AtomicTransaction and WS-BusinessActivity specifications. </para>
+<para>Building on the industry proven Java EE 5 transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The product supports the WS-AtomicTransaction and WS-BusinessActivity specifications. </para>
 </section>
 
 <section>
@@ -4849,8 +6117,8 @@
 
 <section>
 	<title>How does JBossTS address these issues?</title>
-<para>Building on the industry proven J2EE transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The programming interfaces are based on the Java API for XML Transactioning (JAXTX) and the product includes protocol support for the WS-AtomicTransaction and WS-BusinessActivity specifications. JBossTS 4.2 is designed to support multiple coordination protocols and therefore helps to future-proof transactional applications. For a more detailed description of the product capabilities, see the full feature list below for more details. </para>
-<para>JBossTS is a pure Java multi-modal transaction service that supports distributed transactions in CORBA, J2EE and Web services environments.</para>
+<para>Building on the industry proven JEE transaction technology, version 4.0 adds native support for Web services transactions by providing all of the components necessary to build interoperable, reliable, multi-party, Web services-based applications with the minimum of effort. The programming interfaces are based on the Java API for XML Transactioning (JAXTX) and the product includes protocol support for the WS-AtomicTransaction and WS-BusinessActivity specifications. JBossTS 4.2 is designed to support multiple coordination protocols and therefore helps to future-proof transactional applications. For a more detailed description of the product capabilities, see the full feature list below for more details. </para>
+<para>JBossTS is a pure Java multi-modal transaction service that supports distributed transactions in CORBA, JEE and Web services environments.</para>
 <orderedlist>
 <listitem>
 <para>Standards compliance </para>
@@ -4859,7 +6127,7 @@
 <para>CORBA Object Transaction Service (OTS) </para>
 </listitem>
 <listitem>
-<para>Java Enterprise (J2EE) transactions </para>
+<para>Java Enterprise (JEE) transactions </para>
 <orderedlist>
 <listitem>
 <para>Java Transaction API (JTA) </para>
@@ -4886,7 +6154,7 @@
 </orderedlist>
 </listitem>
 <listitem>
-<para>J2EE and CORBA transactioning features </para>
+<para>JEE and CORBA transactioning features </para>
 <orderedlist>
 <listitem>
 <para>Complete distributed transaction support </para>
@@ -4954,7 +6222,7 @@
 <para>Architected for portability across a wide- range of Web services platforms. Supports the open source JBoss application server for highly cost effective development and deployment. </para>
 </listitem>
 <listitem>
-<para>Close integration with enterprise Java standards, allowing Web services transactions to seamlessly integrate with J2EE application servers, messaging systems and database back- ends. </para>
+<para>Close integration with enterprise Java standards, allowing Web services transactions to seamlessly integrate with JEE application servers, messaging systems and database back- ends. </para>
 </listitem>
 <listitem>
 <para>Easy to use Java programming interfaces, based on the emerging JAXTX standard. A rich programming framework reduces overhead in adding transactioning capabilities to Web services. </para>
@@ -4968,6 +6236,72 @@
 </section>
 
 </chapter>
+		<chapter id="jgroups"><title>JGroups</title>
+	
+	<para>
+		JGroups is a toolkit for reliable multicast communication. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code. The following are the key features of JGroup.
+	</para>
+	
+	<orderedlist>
+		<listitem>
+			<para>Group creation and deletion. Group members can be spread across LANs or WANs </para>
+		</listitem>
+		<listitem>
+			<para>Joining and leaving of groups </para>
+		</listitem>
+		<listitem>
+			<para>Membership detection and notification about joined/left/crashed members </para>
+		</listitem>
+		<listitem>
+			<para>Detection and removal of crashed members </para>
+		</listitem>
+		<listitem>
+			<para>Sending and receiving of member-to-group messages (point-to-multipoint) </para>
+		</listitem>
+		<listitem>
+			<para>Sending and receiving of member-to-member messages (point-to-point) </para>
+		</listitem>
+	</orderedlist>
+
+
+	<section>
+		<title>Flexible Protocol Stack</title>
+	<para>
+		The most powerful feature of JGroups is its flexible protocol stack, which allows developers to adapt it to exactly match their application requirements and network characteristics. The benefit of this is that you only pay for what you use. By mixing and matching protocols, various differing application requirements can be satisfied. JGroups comes with a number of protocols (but anyone can write their own), for example.
+	</para>
+	<para>
+	<orderedlist>
+		<listitem>
+			<para>Transport protocols: UDP (IP Multicast), TCP, JMS </para>
+		</listitem>
+		<listitem>
+			<para>Fragmentation of large messages </para>
+		</listitem>
+		<listitem>
+			<para>Reliable unicast and multicast message transmission. Lost messages are retransmitted </para>
+		</listitem>
+		<listitem>
+			<para>Failure detection: crashed members are excluded from the membership </para>
+		</listitem>
+		<listitem>
+			<para>Ordering protocols: Atomic (all-or-none message delivery), Fifo, Causal, Total Order (sequencer or token based) </para>
+		</listitem>
+		<listitem>
+			<para>Membership </para>
+		</listitem>
+		<listitem>
+			<para>Encryption </para>
+		</listitem>
+	</orderedlist>
+</para>
+
+    <para>
+	    More information on JGroups can be found on the <ulink url="http://www.jboss.org/jgroups/">The JGroups homepage</ulink>
+    </para>
+
+</section>
+
+</chapter>
 		<chapter><title>JBoss Messaging 1.4.1</title>
 
 <para>JBoss Messaging is the new enterprise messaging system from JBoss. It is a complete rewrite of JBossMQ, the legacy JBoss JMS provider. It is the default JMS provider on JBoss AS 5. Production support is already available through JBoss EAP 4.3, and we offer developer support for JBoss 4.2.x.</para>
@@ -5006,10 +6340,446 @@
 <para>JBoss Messaging is destined to become an integral part of the JBoss Enterprise Application Platform, and the new Service Integration Platform.</para>
 <para>JBoss Messaging is also an integral part of Red Hat's strategy for messaging. JBoss Messaging is committed to AMQP ( <ulink url="http://www.amqp.org/">AMQP</ulink>)- the new messaging standard from Red Hat and others. Later versions of JBoss Messaging will support AMQP, and JBoss Messaging will be focussed on becoming the premier AMQP Java broker.</para>
 
+<section><title>Configuring JBoss Messaging</title>
+	
 <para>
- ....... more content coming..conversion of doc in progress
+	The JBoss Messaging service configuration is spread among several configuration files. Depending on the functionality provided by the services it configures, the configuration data is distributed between <filename>&lt;JBOSS_HOME&gt;/server/&lt;configuration&gt;/deploy/messaging-service.xml, remoting-service.xml, connection-factories-service.xml, destinations-service.xml and  xxx-persistence-service.xml</filename> (where <literal>xxx</literal> is the name of your database). The default will be <filename>hsqldb-persistence-service.xml</filename> for the hsqldb database.	
 </para>
 
+<section><title>Configuring the SecurityStore</title>
+<para>
+	SecurityStore is a pluggable object, and it has a default implementation on <filename>messaging-service.xml</filename>.
+</para>
+<programlisting role="XML">&lt;server&gt;
+	&lt;mbean code="org.jboss.jms.server.security.SecurityMetadataStore"
+	name="jboss.messaging:service=SecurityStore"&gt;
+	
+	&lt;attribute name="DefaultSecurityConfig"&gt;
+	&lt;security&gt;
+	&lt;role name="guest" read="true" write="true" create="true"/&gt;
+	&lt;/security&gt;
+	&lt;/attribute&gt;
+	
+	&lt;attribute name="SecurityDomain"&gt;java:/jaas/messaging&lt;/attribute&gt;
+	
+	&lt;attribute name="SuckerPassword"&gt;CHANGE ME!!&lt;/attribute&gt;
+&lt;/mbean&gt;
+...
+...file truncated..
+</programlisting>
+</section>
+
+<section><title>SecurityStore Attributes</title>
+<para>The following are SecurityStore attributes from the <filename>messaging-service.xml</filename> file above.
+</para>
+
+<section><title>DefaultSecurityConfig</title>
+	<para>
+		Default security configuration is used when the security configuration for a specific queue or topic has not been overridden in the destination's deployment descriptor. It has exactly the same syntax and semantics as in JBossMQ.
+	</para>
+	<para>
+	The DefaultSecurityConfig attribute element should contain one &lt;security&gt; element. The &lt;security&gt; element can contain multiple &lt;role&gt; elements. Each &lt;role&gt; element defines the default access for that particular role.
+	</para>
+	<para>
+	If the read attribute is true then that role will be able to read (create consumers, receive messaages or browse) destinations by default.
+						
+	If the write attribute is true then that role will be able to write (create producers or send messages) to destinations by default. If the create attribute is true then that role will be able to create durable subscriptions on topics by default.
+	</para>
+</section>
+
+<section><title>SecurityDomain</title>
+	<para>
+		The JAAS security domain to be used by this server peer.
+	</para>
+</section>
+
+<section><title>SuckerPassword</title>
+	<para>
+		This defines how the SecurityStore will authenticate the sucker user (<literal>JBM.SUCKER</literal>).
+	</para>
+</section>
+
+
+
+</section>
+
+</section>
+
+<section><title>Configuring the ServerPeer</title>
+<para>
+	The Server Peer is the heart of the JBoss Messaging JMS facade. The server's configuration, resides in <filename>messaging-service.xml</filename> configuration file.
+	
+	All JBoss Messaging services are rooted at the server peer.
+	
+	An example of a Server Peer configuration is presented below. Note that not all values for the server peer's attributes are specified in the example.
+</para>
+
+<programlisting role="XML">&lt;!-- ServerPeer MBean configuration
+	============================== --&gt;
+	
+	&lt;mbean code="org.jboss.jms.server.ServerPeer"
+	name="jboss.messaging:service=ServerPeer"
+	xmbean-dd="xmdesc/ServerPeer-xmbean.xml"&gt;
+	
+	&lt;!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer --&gt;
+	
+	&lt;attribute name="ServerPeerID"&gt;${jboss.messaging.ServerPeerID:0}&lt;/attribute&gt;
+	
+	&lt;!-- The default JNDI context to use for queues when they are deployed without specifying one --&gt; 
+	
+	&lt;attribute name="DefaultQueueJNDIContext"&gt;/queue&lt;/attribute&gt;
+	
+	&lt;!-- The default JNDI context to use for topics when they are deployed without specifying one --&gt; 
+	
+	&lt;attribute name="DefaultTopicJNDIContext"&gt;/topic&lt;/attribute&gt;
+	
+	&lt;attribute name="PostOffice"&gt;jboss.messaging:service=PostOffice&lt;/attribute&gt;
+	
+	&lt;!-- The default Dead Letter Queue (DLQ) to use for destinations.
+	This can be overridden on a per destinatin basis --&gt;
+	
+	&lt;attribute name="DefaultDLQ"&gt;jboss.messaging.destination:service=Queue,name=DLQ&lt;/attribute&gt;
+	
+	&lt;!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).
+	This can be overridden on a per destinatin basis --&gt;
+	
+	&lt;attribute name="DefaultMaxDeliveryAttempts"&gt;10&lt;/attribute&gt;
+	
+	&lt;!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis --&gt;
+	
+	&lt;attribute name="DefaultExpiryQueue"&gt;jboss.messaging.destination:service=Queue,name=ExpiryQueue&lt;/attribute&gt;
+	
+	&lt;!-- The default redelivery delay to impose. This can be overridden on a per destination basis --&gt;
+	
+	&lt;attribute name="DefaultRedeliveryDelay"&gt;0&lt;/attribute&gt;
+	
+	&lt;!-- The periodicity of the message counter manager enquiring on queues for statistics --&gt;
+	
+	&lt;attribute name="MessageCounterSamplePeriod"&gt;5000&lt;/attribute&gt;
+	
+	&lt;!-- The maximum amount of time for a client to wait for failover to start on the server side after
+	it has detected failure --&gt;
+	
+	&lt;attribute name="FailoverStartTimeout"&gt;60000&lt;/attribute&gt;
+	
+	&lt;!-- The maximum amount of time for a client to wait for failover to complete on the server side after
+	it has detected failure --&gt;
+	
+	&lt;attribute name="FailoverCompleteTimeout"&gt;300000&lt;/attribute&gt;
+	
+	&lt;attribute name="StrictTck"&gt;false&lt;/attribute&gt;
+	
+	&lt;!-- The maximum number of days results to maintain in the message counter history --&gt;
+	
+	&lt;attribute name="DefaultMessageCounterHistoryDayLimit"&gt;-1&lt;/attribute&gt;
+	
+	&lt;!-- The name of the connection factory to use for creating connections between nodes to pull messages --&gt;
+	
+	&lt;attribute name="ClusterPullConnectionFactoryName"&gt;jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory&lt;/attribute&gt;
+	
+	&lt;!-- When redistributing messages in the cluster. Do we need to preserve the order of messages received
+	by a particular consumer from a particular producer? --&gt;
+	
+	&lt;attribute name="DefaultPreserveOrdering"&gt;false&lt;/attribute&gt;
+	
+	&lt;!-- Max. time to hold previously delivered messages back waiting for clients to reconnect after failover --&gt;
+	
+	&lt;attribute name="RecoverDeliveriesTimeout"&gt;300000&lt;/attribute&gt;
+	
+	&lt;!-- The password used by the message sucker connections to create connections.
+	THIS SHOULD ALWAYS BE CHANGED AT INSTALL TIME TO SECURE SYSTEM
+	&lt;attribute name="SuckerPassword"&gt;&lt;/attribute&gt;
+	--&gt;
+	
+	&lt;!-- The name of the server aspects configuration resource
+	&lt;attribute name="ServerAopConfig"&gt;aop/jboss-aop-messaging-server.xml&lt;/attribute&gt;
+	--&gt;
+	&lt;!-- The name of the client aspects configuration resource
+	&lt;attribute name="ClientAopConfig"&gt;aop/jboss-aop-messaging-client.xml&lt;/attribute&gt;
+	--&gt;
+	
+	&lt;depends optional-attribute-name="PersistenceManager"&gt;jboss.messaging:service=PersistenceManager&lt;/depends&gt;
+	
+	&lt;depends optional-attribute-name="JMSUserManager"&gt;jboss.messaging:service=JMSUserManager&lt;/depends&gt;
+	
+	&lt;depends&gt;jboss.messaging:service=Connector,transport=bisocket&lt;/depends&gt;
+	&lt;depends optional-attribute-name="SecurityStore"
+	proxy-type="org.jboss.jms.server.SecurityStore"&gt;jboss.messaging:service=SecurityStore&lt;/depends&gt;
+&lt;/mbean&gt;
+...
+</programlisting>
+
+</section>
+
+<section><title>Server Attributes</title>
+<para>
+	This section discusses the MBean attributes of the ServerPeer MBean.
+</para>
+
+<section><title>ServerPeerID</title>
+<para>
+The unique id of the server peer. Every node you deploy MUST have a unique id. This applies whether the different nodes form a cluster, or are only linked via a message bridge. The id must be a valid integer.
+</para>
+</section>
+
+<section><title>DefaultQueueJNDIContext</title>
+	<para>
+	The default JNDI context to use when binding queues. Defaults to <literal>/queue</literal>.
+	</para>
+</section>
+<section><title>DefaultTopicJNDIContext</title>
+	<para>
+	The default JNDI context to use when binding topics.wa Defaults to <literal>/topic</literal>.
+	</para>
+</section>
+<section><title>PostOffice</title>
+	<para>
+	This is the post office that the ServerPeer uses. You will not normally need to change this attribute. The post office is responsible for routing messages to queues and maintaining the mapping between addresses and queues.
+	</para>
+</section>
+<section><title>DefaultDLQ</title>
+	<para>
+	This is the name of the default DLQ (Dead Letter Queue) the server peer will use for destinations. The DLQ can be overridden on a per destination basis - see the destination MBean configuration for more details. A DLQ is a special destination where messages are sent when the server has attempted to deliver them unsuccessfully more than a certain number of times. If the DLQ is not specified at all then the message will be removed after the maximum number of delivery attempts. The maximum number of delivery attempts can be specified using the attribute DefaultMaxDeliveryAttempts for a global default or individually on a per destination basis.
+	</para>
+</section>
+<section><title>DefaultMaxDeliveryAttempts</title>
+	<para>
+	The default for the maximum number of times delivery of a message will be attempted before sending the message to the DLQ, if configured.
+	</para>
+	<para>The default value is 10.This value can also be overridden on a per destination basis.
+	</para>
+</section>
+<section><title>DefaultExpiryQueue</title>
+	<para>
+		This is the name of the default expiry queue the server peer will use for destinations. The expiry can be overridden on a per destination basis - see the destination MBean configuration for more details. An expiry queue is a special destination where messages are sent when they have expired. Message expiry is determined by the value of Message::getJMSExpiration() If the expiry queue is not specified at all then the message will be removed after it is expired.
+	</para>
+</section>
+<section><title>DefaultRedeliveryDelay</title>
+	<para>
+		When redelivering a message after failure of previous delivery it is often beneficial to introduce a delay perform redelivery in order to prevent thrashing of delivery-failure, delivery-failure etc.
+	</para>
+	<para>
+	The default value is 0 which means there will be no delay.
+	</para>
+	<para>
+	Change this if your application could benefit with a delay before redelivery. This value can also be overridden on a per destination basis.
+	</para>
+</section>
+<section><title>MessageCounterSamplePeriod</title>
+	<para>
+		Periodically the server will query each queue to gets its statistics. This is the period.
+	</para>
+	<para>
+		The default value is 10000 milliseconds.
+	</para>
+</section>
+<section><title>FailoverStartTimeout</title>
+	<para>
+		The maximum number of milliseconds the client will wait for failover to start on the server side when a problem is detected.
+	</para>
+	<para>
+		The default value is 60000 (one minute).
+	</para>
+</section>
+<section><title>FailoverCompleteTimeout</title>
+	<para>
+		The maximum number of milliseconds the client will wait for failover to complete on the server side after it has started. The default value is 300000 (five minutes).
+	</para>
+</section>
+<section><title>DefaultMessageCounterHistoryDayLimit</title>
+	<para>
+		JBoss Messaging provides a message counter history which shows the number of messages arriving on each queue of a certain number of days. This attribute represents the maxiumum number of days for which to store message counter history. It can be overridden on a per destination basis.
+	</para>
+</section>
+<section><title>ClusterPullConnectionFactory</title>
+	<para>
+		The name of the connection factory to use for pulling messages between nodes.
+		If you wish to turn off message sucking between queues altogether, but retain failover, then you can ommit this attribute altogether.
+	</para>
+</section>
+<section><title>DefaultPreserveOrdering</title>
+	<para>
+		If true, then strict JMS ordering is preserved in the cluster. See the cluster configurations section for more details. Default is false.
+	</para>
+</section>
+<section><title>RecoverDeliveriesTimeout</title>
+	<para>
+		When failover occurs, already delivered messages will be kept aside, waiting for clients to reconnect. In the case that clients never reconnect (e.g. the client is dead) then eventually these messages will timeout and be added back to the queue. The value is in ms. The default is 5 mins.
+	</para>
+</section>
+<section><title>SuckerPassword</title>
+		<para>
+		JBoss Messaging internally makes connections between nodes in order to redistribute messages between clustered destinations. These connections are made with the user name of a special reserved user. On this parameter you define the password used as these connections are made. After JBossMessaging 1.4.1.GA you will need to define the Sucker Password on the ServerPeer and on the SecurityMetadataStore.
+	</para>
+<warning><title>Warning</title>
+<para>This must be specified at install time, or the default password will be used. Any one who then knows the default password will be able to gain access to any destinations on the server. This value MUST be changed at install time.</para>
+</warning>
+</section>
+<section><title>StrictTCK</title>
+	<para>Set to true if you want strict JMS TCK semantiocs
+	</para>
+</section>
+<section><title>Destinations</title>
+	<para>
+		Returns a list of the destinations (queues and topics) currently deployed.
+	</para>
+</section>
+<section><title>MessageCounters</title>
+	<para>
+		JBoss Messaging provides a message counter for each queue.
+	</para>
+</section>
+<section><title>MessageCountersStatistics</title>
+	<para>
+		JBoss Messaging provides statistics for each message counter for each queue.
+	</para>
+</section>
+<section><title>SupportsFailover</title>
+<para>
+	Set to false to prevent server side failover occurring in a cluster when a node crashes.
+</para>
+</section>
+<section><title>PersistenceManager</title>
+	<para>
+		This is the persistence manager that the ServerPeer uses. You will not normally need to change this attribute.
+	</para>
+</section>
+<section><title>JMSUserManager</title>
+	<para>
+		This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
+	</para>
+</section>
+<section><title>SecurityStore</title>
+	<para>
+		This is the pluggable SecurityStore. If you redefine this SecurityStore, notice it will need to authenticate the MessageSucker user ("JBM.SUCKER") with all the special permissions required by clustering.
+	</para>
+</section>
+
+</section>
+
+<section><title>MBean operations of the ServerPeer MBean</title>
+	<para>
+	</para>
+
+<section><title>DeployQueue</title>
+	<para>
+		This operation lets you programmatically deploy a queue. There are two overloaded versions of this operation. If the queue already exists but is undeployed it is deployed. Otherwise it is created and deployed. The <literal>name</literal> parameter represents the name of the destination to deploy. The <literal>jndiName</literal> parameter (optional) represents the full jndi name where to bind the destination. If this is not specified then the destination will be bound in <literal>&lt;DefaultQueueJNDIContext&gt;/&lt;name&gt;</literal>.
+	</para>
+	<para>
+		The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the paging parameters mean.
+	</para>
+</section>
+<section><title>UndeployQueue</title>
+	<para>
+		This operation lets you programmatically undeploy a queue.
+		The queue is undeployed but is NOT removed from persistent storage.
+		This operation returns true if the queue was successfull undeployed. otherwise it returns false.
+	</para>
+</section>
+<section><title>DestroyQueue</title>
+	<para>
+		This operation lets you programmatically destroy a queue.
+		The queue is undeployed and then all its data is destroyed from the database.
+	
+	
+<warning><title>Warning</title>
+<para>Be cautious when using this method since it will delete all data for the queue.</para>
+</warning>
+	
+		This operation returns true if the queue was successfully destroyed. otherwise it returns false.
+	</para>
+
+</section>
+<section><title>DeployTopic</title>
+	<para>
+		This operation lets you programmatically deploy a topic.
+	</para>
+	<para>
+		There are two overloaded versions of this operation.
+	</para>	
+	<para>
+		If the topic already exists but is undeployed it is deployed. Otherwise it is created and deployed.
+	</para>
+	<para>
+		The name parameter represents the name of the destination to deploy.
+	</para>
+	<para>
+		The jndiName parameter (optional) represents the full jndi name where to bind the destination. If this is not specified then the destination will be bound in &lt;DefaultTopicJNDIContext&gt;/&lt;name&gt;.
+	</para>
+	<para>
+		The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the paging parameters mean.
+	</para>
+
+</section>
+<section><title>UndeployTopic</title>
+	<para>
+		This operation lets you programmatically undeploy a topic.
+		The queue is undeployed but is NOT removed from persistent storage.
+		This operation returns true if the topic was successfully undeployed. otherwise it returns false.
+	</para>
+</section>
+<section><title>DestroyTopic</title>
+<para>
+	This operation lets you programmatically destroy a topic.
+</para>
+<para>
+	The topic is undeployed and then all its data is destroyed from the database.
+
+<warning><title>Warning</title>
+	<para>
+	Be careful when using this method since it will delete all data for the topic.
+	</para>
+</warning>				
+					This operation returns true if the topic was successfully destroyed. otherwise it returns false.
+	</para>
+	</section>
+<section><title>ListMessageCountersHTML</title>
+	<para>
+		This operation returns message counters in an easy to display HTML format.
+	</para>
+</section>
+<section><title>ResetAllMesageCounters</title>
+	<para>
+		This operation resets all message counters to zero.
+	</para>
+</section>
+<section><title>ResetAllMesageCounters</title>
+	<para>
+		This operation resets all message counter histories to zero.
+	</para>
+</section>
+<section><title>EnableMessageCounters</title>
+	<para>
+		This operation enables all message counters for all destinations. Message counters are disabled by default.
+	</para>
+</section>
+<section><title>DisableMessageCounters</title>
+	<para>
+		This operation disables all message counters for all destinations. Message counters are disabled by default.
+	</para>
+</section>
+<section><title>RetrievePreparedTransactions</title>
+	<para>
+		Retrieves a list of the Xids for all transactions currently in a prepared state on the node.
+	</para>
+</section>
+<section><title>ShowPreparedTransactions</title>
+	<para>
+		Retrieves a list of the Xids for all transactions currently in a prepared state on the node in an easy to display HTML format.
+	</para>
+</section>
+	
+	
+</section>
+
+
+
+
+
+
+
+
+
 </chapter>
 		
 	</part>
@@ -8958,7 +10728,7 @@
     <para>JBoss utilizes the Hypersonic database as its default database. While this is good for development and prototyping, you or your company will probably require another database to be used for production. This chapter covers configuring JBoss AS to use alternative databases. We cover the procedures for all officially supported databases on the JBoss Application Server. They include: MySQL 5.0, PostgreSQL 8.1, Oracle 9i and 10g R2, DB2 7.2 and 8, Sybase ASE 12.5, as well as MS SQL 2005.
     </para>
 		
-    <para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss AS. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss AS, you can still use any backend database by setting up the appropriate data source connection as described in <xref linkend="Connectors_on_JBoss-Configuring_JDBC_DataSources"/>.</para>
+    <para>Please note that in this chapter, we explain how to use alternative databases to support all services in JBoss AS. This includes all the system level services such as EJB and JMS. For individual applications (e.g., WAR or EAR) deployed in JBoss AS, you can still use any backend database by setting up the appropriate data source connection. </para>
         
     <para>We assume that you have already installed the external database server, and have it running. You should create an empty database named <literal>jboss</literal>, accessible via the username / password pair <literal>jbossuser / jbosspass</literal>. The <literal>jboss</literal> database is used to store JBoss AS internal data -- JBoss AS will automatically create tables and data in it.</para>