[jboss-cvs] JBossAS SVN: r83791 - in projects/docs/enterprise: 4.3.4/readme/en-US and 1 other directory.

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

Author: irooskov at redhat.com
Date: 2009-02-02 22:22:20 -0500 (Mon, 02 Feb 2009)
New Revision: 83791

Modified:
   projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml
   projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
Log:
corrected spelling


Modified: projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml
===================================================================
--- projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml	2009-02-03 02:49:21 UTC (rev 83790)
+++ projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml	2009-02-03 03:22:20 UTC (rev 83791)
@@ -323,7 +323,7 @@
 			<itemizedlist>
 				<listitem>
 					<para>
-						<filename>Installation Guide</filename> explains how to install and verify the installation of JBoss Enteprise Application Platform using different installation modes.
+						<filename>Installation Guide</filename> explains how to install and verify the installation of JBoss Enterprise Application Platform using different installation modes.
 					</para>
 				</listitem>
 				<listitem>
@@ -376,7 +376,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <classname>JDBCExtCacheLoader</classname> did not handle persistent state transfer correctly since the <methodname>JDBCExtCacheLoader.storeState()</methodname> method would use avaliable bytes on the <classname>MarshalledValueInputStream</classname> rather than on the <classname>ByteArrayInputStream</classname> when storing the persistent state. This was an issue because the <classname>MarshalledValueInputStream</classname> always returns a null value, meaning the persistent state was never written. In fixing this issue the <filename>JDBCExtendedCacheLoader.java</filename> file has been modified so that it specifies to check for avaliable space on the <classname>ByteArrayInputStream</classname>. 
+									The <classname>JDBCExtCacheLoader</classname> did not handle persistent state transfer correctly since the <methodname>JDBCExtCacheLoader.storeState()</methodname> method would use available bytes on the <classname>MarshalledValueInputStream</classname> rather than on the <classname>ByteArrayInputStream</classname> when storing the persistent state. This was an issue because the <classname>MarshalledValueInputStream</classname> always returns a null value, meaning the persistent state was never written. In fixing this issue the <filename>JDBCExtendedCacheLoader.java</filename> file has been modified so that it specifies to check for available space on the <classname>ByteArrayInputStream</classname>. 
 								</para>
 							</listitem>
 						</itemizedlist>
@@ -405,7 +405,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									A bug existed within the Remoting component by which the RemotingClassLoader would always attempt to load a class over the network first if remote classloading was enabled, leading to conflicts if the class was avaliable locally before. The code has been corrected to check locally first before looking remotely. 
+									A bug existed within the Remoting component by which the RemotingClassLoader would always attempt to load a class over the network first if remote classloading was enabled, leading to conflicts if the class was available locally before. The code has been corrected to check locally first before looking remotely. 
 								</para>
 							</listitem>
 							<listitem>
@@ -415,7 +415,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <classname>HTTPClientInvoker</classname> did not support Beginner's All-purpose Symbolic Instruction Code (BASIC) authentication for proxies when the proxy was configured through system property options of <methodname>http.proxyHost</methodname> and <methodname>http.proxyPort</methodname>. The issue appears because the <classname>HTTPClientInvoker</classname> would not check for the existence of these options and in tern it would never create a <methodname>Proxy-Authorization</methodname> request header, which is necessary for normal opperation. To fix this the <classname>HTTPClientInvoker</classname> has been modified to check for the existence of the <methodname>http.proxyHost</methodname> option and if it detects its use, creates a <methodname>Proxy-Authorization</methodname> request header.
+									The <classname>HTTPClientInvoker</classname> did not support Beginner's All-purpose Symbolic Instruction Code (BASIC) authentication for proxies when the proxy was configured through system property options of <methodname>http.proxyHost</methodname> and <methodname>http.proxyPort</methodname>. The issue appears because the <classname>HTTPClientInvoker</classname> would not check for the existence of these options and in tern it would never create a <methodname>Proxy-Authorization</methodname> request header, which is necessary for normal operation. To fix this the <classname>HTTPClientInvoker</classname> has been modified to check for the existence of the <methodname>http.proxyHost</methodname> option and if it detects its use, creates a <methodname>Proxy-Authorization</methodname> request header.
 								</para>
 							</listitem>
 							<listitem>
@@ -425,7 +425,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									Within the <classname>InvokerRegistry</classname> an error existed associated with the sequencing of events and <classname>serverLocators</classname>  would return a null on occasion. To correct this race condition, the sequencing of events within the <classname>InvokerRegistry</classname> has been rearragned so that references to <classname>transportClientFactoryClasses</classname> and <classname>clientLocators</classname> are governed by <classname>clientLock</classname> and references to <classname>transportServerFactoryClasses</classname>, <classname>serverLocators</classname>, and <classname>registeredLocators</classname> are governed by <classname>serverLock</classname>.
+									Within the <classname>InvokerRegistry</classname> an error existed associated with the sequencing of events and <classname>serverLocators</classname>  would return a null on occasion. To correct this race condition, the sequencing of events within the <classname>InvokerRegistry</classname> has been rearranged so that references to <classname>transportClientFactoryClasses</classname> and <classname>clientLocators</classname> are governed by <classname>clientLock</classname> and references to <classname>transportServerFactoryClasses</classname>, <classname>serverLocators</classname>, and <classname>registeredLocators</classname> are governed by <classname>serverLock</classname>.
 								</para>
 							</listitem>
 							<listitem>
@@ -435,12 +435,12 @@
 							</listitem>
 							<listitem>
 								<para>
-									<classname>ConnectionValidator</classname> may become unresponsive then the <methodname>run()</methodname> method is executed and utilizes the <varname>lock</varname> variable. The methods within the <methodname>run()</methodname> method are meant to time out so that the <varname>lock</varname> variable can become avaliable to the <methodname>notifyListeners()</methodname> in the event of a network failure; however <methodname>run()</methodname> may execute again before <methodname>notifyListeners()</methodname> can. The synchronization on the <varname>lock</varname> variable has been modified to avoid this issue to enable correct operation.
+									<classname>ConnectionValidator</classname> may become unresponsive then the <methodname>run()</methodname> method is executed and utilizes the <varname>lock</varname> variable. The methods within the <methodname>run()</methodname> method are meant to time out so that the <varname>lock</varname> variable can become available to the <methodname>notifyListeners()</methodname> in the event of a network failure; however <methodname>run()</methodname> may execute again before <methodname>notifyListeners()</methodname> can. The synchronization on the <varname>lock</varname> variable has been modified to avoid this issue to enable correct operation.
 								</para>
 							</listitem>
 							<listitem>
 								<para>
-									During occurances of the server being under heavy load, an <exceptionname>IllegalStateException</exceptionname> would occur within the <methodname>ConnectorValidator.run()</methodname> method because further synchronization on the <varname>lock</varname> variable was necessary. This issue was fixed during the rectification of the above problem. 
+									During occurrences of the server being under heavy load, an <exceptionname>IllegalStateException</exceptionname> would occur within the <methodname>ConnectorValidator.run()</methodname> method because further synchronization on the <varname>lock</varname> variable was necessary. This issue was fixed during the rectification of the above problem. 
 								</para>
 							</listitem>
 							<listitem>
@@ -464,7 +464,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1493">JBPAPP-1493</ulink>: An error would be shown on occassion by <emphasis>Internet Explorer</emphasis> because xml content would not be sent when <emphasis>PROPFIND</emphasis> requests were being used. This has been fixed by creating a new method within <filename>WebdavServlet.java</filename> that overrides the <methodname>DefaultServlet</methodname> implementation for servlet request processing and testing for input before launching the <methodname>DocumentBuilder</methodname>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1493">JBPAPP-1493</ulink>: An error would be shown on occasion by <emphasis>Internet Explorer</emphasis> because xml content would not be sent when <emphasis>PROPFIND</emphasis> requests were being used. This has been fixed by creating a new method within <filename>WebdavServlet.java</filename> that overrides the <methodname>DefaultServlet</methodname> implementation for servlet request processing and testing for input before launching the <methodname>DocumentBuilder</methodname>.
 						</para>
 					</listitem>
 					<listitem>
@@ -501,7 +501,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP-1553</ulink>: When the <methodname>parseRequest()</methodname> method of the <classname>org.jboss.seam.web.MultipartRequest</classname> class uploaded a large file, there were occurances when this would cause an endless loop and use 100% of the computers CPU. In order to break out of the loop, a <varname>loopCounter</varname> has been implemented within the <filename>MultipartRequest.java</filename> file. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP-1553</ulink>: When the <methodname>parseRequest()</methodname> method of the <classname>org.jboss.seam.web.MultipartRequest</classname> class uploaded a large file, there were occurrences when this would cause an endless loop and use 100% of the computers CPU. In order to break out of the loop, a <varname>loopCounter</varname> has been implemented within the <filename>MultipartRequest.java</filename> file. 
 						</para>
 					</listitem>
 					<listitem>
@@ -528,7 +528,7 @@
 						<itemizedlist>
 							<listitem>
 								<para>
-									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1628</ulink>: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existance of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection.
+									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1628</ulink>: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existence of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection.
 								</para>
 								<para>
 									<filename>AbstractEntityPersister.java</filename> has been updated to execute a prepared statement on the result set and after calculating the <varname>propValue</varname> the result set is closed if it is not null; ensuring that no leak can occur.
@@ -571,12 +571,12 @@
 							</listitem> -->
 							<listitem>
 								<para>
-									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1519</ulink>: Sybase does not support the opperation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both opperate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false.
+									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1519</ulink>: Sybase does not support the operation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both operate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false.
 								</para>
 							</listitem>
 							<listitem>
 								<para>
-									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1496">JBPAPP-1496</ulink>: A memory leak existed because of an unclosed <emphasis>ResultSet</emphasis> when using the <emphasis>Identity</emphasis> generator option. To close the memory leak, the <emphasis>ResultSet</emphasis> is checked to make sure it is closed before returning the generated itentity value. 
+									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1496">JBPAPP-1496</ulink>: A memory leak existed because of an unclosed <emphasis>ResultSet</emphasis> when using the <emphasis>Identity</emphasis> generator option. To close the memory leak, the <emphasis>ResultSet</emphasis> is checked to make sure it is closed before returning the generated identity value. 
 								</para>
 							</listitem>
 							<listitem>
@@ -606,7 +606,7 @@
 								</listitem>
 							</itemizedlist>
 							<para>
-								To fix this isue the <filename>AbstractEntityPersister.java</filename> file was updated so that the <varname>columnNumber</varname> variable is passed to the <methodname>subclassColumnSelectableClosure</methodname> method instead of an increment of the for loop variable <varname>i</varname>.
+								To fix this issue the <filename>AbstractEntityPersister.java</filename> file was updated so that the <varname>columnNumber</varname> variable is passed to the <methodname>subclassColumnSelectableClosure</methodname> method instead of an increment of the for loop variable <varname>i</varname>.
 							</para>
 							<para>
 								<filename>CollectionTest.java</filename> has also been updated and <filename>Animal.java</filename>, <filename>Mammal.java</filename>, <filename>Zoo.hbm.xml</filename> and <filename>Zoo.java</filename> have been added for testing purposes.
@@ -614,7 +614,7 @@
 						</listitem>
 						<listitem>
 							<para>
-								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1467">JBPAPP-1467</ulink>: A <exceptionname>PropertyValueException</exceptionname> would occur when merging a detached instance of a <classname>One</classname> class that contains a new <classname>Many</classname> class instance and if and only if the <classname>One</classname> class was previously loaded as a proxy during the same transaction. The files <filename>StatefulPersistenceContext.java</filename>, <filename>BackrefPropertyAccessor.java</filename>, <filename>BackrefTest.java</filename> and <filename>Child.java</filename> have been updated to check for the proxy issue in the mergining and once the proxy entity is found the <methodname>mergeMap</methodname> is updated to deal with this eventuality.
+								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1467">JBPAPP-1467</ulink>: A <exceptionname>PropertyValueException</exceptionname> would occur when merging a detached instance of a <classname>One</classname> class that contains a new <classname>Many</classname> class instance and if and only if the <classname>One</classname> class was previously loaded as a proxy during the same transaction. The files <filename>StatefulPersistenceContext.java</filename>, <filename>BackrefPropertyAccessor.java</filename>, <filename>BackrefTest.java</filename> and <filename>Child.java</filename> have been updated to check for the proxy issue in the merging and once the proxy entity is found the <methodname>mergeMap</methodname> is updated to deal with this eventuality.
 							</para>
 						</listitem>
 						<listitem>
@@ -624,17 +624,17 @@
 						</listitem>
 						<listitem>
 							<para>
-								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has expectly said that the version field should not be updated and does not update the field if this is the case. 
+								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has explicitly said that the version field should not be updated and does not update the field if this is the case. 
 							</para>
 						</listitem>
 						<listitem>
 							<para>
-								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP-1251</ulink>: Filters that were enabled for Hibernate did not apply to update and delete Hibernate Query Language (HQL) statements. In correcting this bug numerious files have been updated to ensure that the filters work correctly. This fix is related to JBPAPP-1250 below.
+								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP-1251</ulink>: Filters that were enabled for Hibernate did not apply to update and delete Hibernate Query Language (HQL) statements. In correcting this bug numerous files have been updated to ensure that the filters work correctly. This fix is related to JBPAPP-1250 below.
 							</para>
 						</listitem>
 						<listitem>
 							<para>
-								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1250">JBPAPP-1250</ulink>: When creating queries with subqueries in Hibernate, any added filters would only apply to the top-level of the query and not to any subquery component or beneath. The Criteria code and HQL code asociated with this has undergone significant re-tooling to allow filters to work appropriatly with subqueries and extent as far as the Hibernate Query Language does.  
+								<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1250">JBPAPP-1250</ulink>: When creating queries with subqueries in Hibernate, any added filters would only apply to the top-level of the query and not to any subquery component or beneath. The Criteria code and HQL code associated with this has undergone significant re-tooling to allow filters to work appropriately with subqueries and extent as far as the Hibernate Query Language does.  
 							</para>
 							<para>
 								Though this is a significant fix to Hibernate, it has been included within this CP release because of its undeniable advantage to all users and ensures that filters on queries operate how a user would expect them to.
@@ -666,7 +666,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									There were occurances when the <classname>AppServerJDBCXARecovery</classname> class would contain information to an invalid connection because of database failure. This bug was fixed with the same correction as the above issue, which is, by modifying the <classname>AppServerJDBCXARecovery</classname> class and adding the <methodname>createConnection() throws SQLException</methodname> method which makes sure a connection exists. 
+									There were occurrences when the <classname>AppServerJDBCXARecovery</classname> class would contain information to an invalid connection because of database failure. This bug was fixed with the same correction as the above issue, which is, by modifying the <classname>AppServerJDBCXARecovery</classname> class and adding the <methodname>createConnection() throws SQLException</methodname> method which makes sure a connection exists. 
 								</para>
 							</listitem>
 							<listitem>
@@ -676,7 +676,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									<methodname>TransactionImple.doOnePhaseCommit</methodname> would generate a <exceptionname>HeuristicRollbackException</exceptionname> when the commit was aborted. This meant that <methodname>XATerminatorImple.commit</methodname> was unable to distingush between a successful rollback and one in error. Fixed in this CP release, the <filename>TransactionImple.java</filename> file has been modified so that the <methodname>TransactionImple.doOnePhaseCommit</methodname> method now generates a <exceptionname>RollbackException</exceptionname> instead of a heuristic when a successful rollback is performed.
+									<methodname>TransactionImple.doOnePhaseCommit</methodname> would generate a <exceptionname>HeuristicRollbackException</exceptionname> when the commit was aborted. This meant that <methodname>XATerminatorImple.commit</methodname> was unable to distinguish between a successful rollback and one in error. Fixed in this CP release, the <filename>TransactionImple.java</filename> file has been modified so that the <methodname>TransactionImple.doOnePhaseCommit</methodname> method now generates a <exceptionname>RollbackException</exceptionname> instead of a heuristic when a successful rollback is performed.
 								</para>
 							</listitem>
 							<listitem>
@@ -710,7 +710,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1565">JBPAPP-1565</ulink>: An exploit existed within the JBoss Web Services component of the EAP that would allow anyone to view any xml file from any location if <literal>&amp;resource=path/of/an/xmlfile.xml</literal> was applied to the end of any WSDL (Web Services Definition Language) access URL. The <filename>WSDLRequestHandler.java</filename> file has been updated to only allow the parent of a WSDL file, a servers data or WSDL or overriden WSDL publish directories access to xml file resources. Additional test files are also included which were created to ensure proper opperation was being undertaken. (CVE-2009-0027 )
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1565">JBPAPP-1565</ulink>: An exploit existed within the JBoss Web Services component of the EAP that would allow anyone to view any xml file from any location if <literal>&amp;resource=path/of/an/xmlfile.xml</literal> was applied to the end of any WSDL (Web Services Definition Language) access URL. The <filename>WSDLRequestHandler.java</filename> file has been updated to only allow the parent of a WSDL file, a servers data or WSDL or overridden WSDL publish directories access to xml file resources. Additional test files are also included which were created to ensure proper operation was being undertaken. (CVE-2009-0027 )
 						</para>
 					</listitem>
 				</itemizedlist>
@@ -749,7 +749,7 @@
 						<itemizedlist>
 							<listitem>
 								<para>
-									A bug existed that would cause <filename>JacORB 2.3.0.jboss5</filename> to become unresponsive during shutdown. In rectifing this issue, the <filename>POA.java</filename> file has been modified so that instead of executing:
+									A bug existed that would cause <filename>JacORB 2.3.0.jboss5</filename> to become unresponsive during shutdown. In rectifying this issue, the <filename>POA.java</filename> file has been modified so that instead of executing:
 								</para>
 								<programlisting>
 									throw new org.omg.CORBA.OBJECT_NOT_EXIST();
@@ -785,7 +785,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1540">JBPAPP-1540</ulink>: Within the cluster section of the EAP, the <classname>GossipRouter</classname> and <classname>GossipClient</classname> (TCPGOSSIP) did not have socket read timeouts, socket linger timeouts and backlog set to provide the best behaviour when heavily utilized or under network situations in need of improvement. This fix provides default values and configuration options for these in order to avoid problematic situations. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1540">JBPAPP-1540</ulink>: Within the cluster section of the EAP, the <classname>GossipRouter</classname> and <classname>GossipClient</classname> (TCPGOSSIP) did not have socket read timeouts, socket linger timeouts and backlog set to provide the best behavior when heavily utilized or under network situations in need of improvement. This fix provides default values and configuration options for these in order to avoid problematic situations. 
 						</para>
 					</listitem>
 					<listitem>
@@ -800,7 +800,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1535">JBPAPP-1535</ulink>: The JDBCExtCacheLoader didn't handle persistent state transfter correctly since the <methodname>storeState</methodname> method would use avaliable space on the <classname>MarshalledValueInputStream</classname> instead of on the <classname>ByteArrayInputStream</classname>. To correct the stream usage, <filename>JDBCExtendedCacheLoader.java</filename> has been updated to store the new state using the <varname>in_stream</varname> value as long as there is space avaliable.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1535">JBPAPP-1535</ulink>: The JDBCExtCacheLoader didn't handle persistent state transfer correctly since the <methodname>storeState</methodname> method would use available space on the <classname>MarshalledValueInputStream</classname> instead of on the <classname>ByteArrayInputStream</classname>. To correct the stream usage, <filename>JDBCExtendedCacheLoader.java</filename> has been updated to store the new state using the <varname>in_stream</varname> value as long as there is space available.
 						</para>
 					</listitem>
 					<listitem>
@@ -830,7 +830,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <literal>Gossip Router</literal> component of JGroups provided options to set <literal>backlog</literal>, <literal>socket read timeout</literal> and <literal>socket linger timeout</literal> within the code, however these options are not avaliable via the command line. This update of the JGroups component, now includes the availability of these options to be set through the command line. 
+									The <literal>Gossip Router</literal> component of JGroups provided options to set <literal>backlog</literal>, <literal>socket read timeout</literal> and <literal>socket linger timeout</literal> within the code, however these options are not available via the command line. This update of the JGroups component, now includes the availability of these options to be set through the command line. 
 								</para>
 							</listitem>
 							<listitem>
@@ -847,7 +847,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1530">JBPAPP-1530</ulink>: The JCA adapter inflow did not roll back messages if a non-xa connection factory was being used within the JNDIProviderAdapter. In order to fix this issue the <filename>JmsServerSession.java</filename> file has been updated with added logic to the local transaction  seperation strategy as to allow for non-xa sessions to be rolled back using transaction session.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1530">JBPAPP-1530</ulink>: The JCA adapter inflow did not roll back messages if a non-xa connection factory was being used within the JNDIProviderAdapter. In order to fix this issue the <filename>JmsServerSession.java</filename> file has been updated with added logic to the local transaction  separation strategy as to allow for non-xa sessions to be rolled back using transaction session.
 						</para>
 					</listitem>
 					<listitem>
@@ -860,7 +860,7 @@
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1479">JBPAPP-1479</ulink>: Within the different distributions of the EAP that are 4.2 and 4.3, both the <filename>JBossMQ</filename> and <filename>JBoss Messaging</filename> application policies have been present within the <filename>login-config.xml</filename> file, when <filename>JBossMQ</filename> is only included in the 4.2 distribution and <filename>JBoss Messaging</filename> is similarly only included in the 4.3 distribution.
 						</para>
 						<para>
-							This has been rectified in this release by modifying <filename>build.xml</filename> and <filename>login-config.xml</filename> to differentiate between requirements for each individial distribution. 
+							This has been rectified in this release by modifying <filename>build.xml</filename> and <filename>login-config.xml</filename> to differentiate between requirements for each individual distribution. 
 						</para>
 					</listitem>
 					<listitem>
@@ -870,12 +870,12 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1460">JBPAPP-1460</ulink>: The JavaServer Faces (JSF) has been updated to version 1.2_10 for this EAP release. This update corrects numerious bugs and details on these fixes can be found at <ulink url="https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html">https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html</ulink>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1460">JBPAPP-1460</ulink>: The JavaServer Faces (JSF) has been updated to version 1.2_10 for this EAP release. This update corrects numerous bugs and details on these fixes can be found at <ulink url="https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html">https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html</ulink>
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1366">JBPAPP-1366</ulink>: Creation of the EJB <filename>TIMERS</filename> table fails when the <option>Oracle</option> schema is specified. To correct this the <filename>GeneralPurposeDatabasePersistencePlugin.java</filename> file has been updated with a calling to an new <methodname>SQLUtil.fixConstraintName</methodname> function which changes all dots in a constraint name to underscores. This ensures that constraint names are compatable with Oracle.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1366">JBPAPP-1366</ulink>: Creation of the EJB <filename>TIMERS</filename> table fails when the <option>Oracle</option> schema is specified. To correct this the <filename>GeneralPurposeDatabasePersistencePlugin.java</filename> file has been updated with a calling to an new <methodname>SQLUtil.fixConstraintName</methodname> function which changes all dots in a constraint name to underscores. This ensures that constraint names are compatible with Oracle.
 						</para>
 					</listitem>
 					<listitem>
@@ -897,12 +897,12 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1275">JBPAPP-1275</ulink>: The Xalan part of the EAP has been upgraded from version 2.7.0 to 2.7.0.patch02. This upgrade removes the circumstance where an application which heavily used Xalan within large multi-threaded environments would encounter blocking situatinos.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1275">JBPAPP-1275</ulink>: The Xalan part of the EAP has been upgraded from version 2.7.0 to 2.7.0.patch02. This upgrade removes the circumstance where an application which heavily used Xalan within large multi-threaded environments would encounter blocking situations.
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1267">JBPAPP-1267</ulink>: <classname>UserTransaction</classname> (UT) was not able to be deployed with a clustered proxy that supported sticky transactions correctly. This has been fixed by modifying numerious files which make <classname>UserTransaction</classname> deployable with transaction sticky load balance policies. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1267">JBPAPP-1267</ulink>: <classname>UserTransaction</classname> (UT) was not able to be deployed with a clustered proxy that supported sticky transactions correctly. This has been fixed by modifying numerous files which make <classname>UserTransaction</classname> deployable with transaction sticky load balance policies. 
 						</para>
 					</listitem>
 					<listitem>
@@ -912,7 +912,7 @@
 						<itemizedlist>
 							<listitem>
 								<para>
-									A mixed EL expression ending with a  literal failed to parse as a managed bean property value. The <filename>BeanBuilder.java</filename> file was updarted with the removal of <code>ELUtils.getScope(this.expressionString, segment);</code> in order to fix this issue.
+									A mixed EL expression ending with a  literal failed to parse as a managed bean property value. The <filename>BeanBuilder.java</filename> file was updated with the removal of <code>ELUtils.getScope(this.expressionString, segment);</code> in order to fix this issue.
 								</para>
 							</listitem>
 							<listitem>
@@ -937,7 +937,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									An issue was present that would cause majarra to execute <filename>faces-config.xml </filename> initialization files twice, creating duplicate operations. This was caused since a record was not kept of which files had been intialized and which had not. File initialization tracking has been implemented to correct this issue and this has seen the modification of the following files: <filename>ConfigManager.java</filename>, <filename>ConfigureListener.java</filename>, <filename>WebConfiguration.java</filename>, <filename>ConfigurationResourceProvider.java</filename>, <filename>MetaInfResourceProvider.java</filename>, <filename>RIConfigResourceProvider.java</filename> and <filename>WebResourceProvider.java</filename>.
+									An issue was present that would cause majarra to execute <filename>faces-config.xml </filename> initialization files twice, creating duplicate operations. This was caused since a record was not kept of which files had been initialized and which had not. File initialization tracking has been implemented to correct this issue and this has seen the modification of the following files: <filename>ConfigManager.java</filename>, <filename>ConfigureListener.java</filename>, <filename>WebConfiguration.java</filename>, <filename>ConfigurationResourceProvider.java</filename>, <filename>MetaInfResourceProvider.java</filename>, <filename>RIConfigResourceProvider.java</filename> and <filename>WebResourceProvider.java</filename>.
 								</para>
 							</listitem>
 							<listitem>
@@ -952,7 +952,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> did not allow for empty <varname>columnClasses</varname> when generating columns from user unput. The issue was realizing when to create numerious columns rather just one; for instance if the user input <literal>foo, </literal> with a trailing space then the expected output would be one column with the name <literal>foo</literal> and another empty column. This was not the case though, as <literal>foo, </literal> would generate just one column with <literal>foo, </literal> in its entirety as the column name, instead of spliting the columns on the comma. This behaviour has now been corrected so that <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> no generates columns correctly, and in order to achieve this the following files have been updated: <filename>BasetableRenderer.java</filename>, <filename>GridRenderer.java</filename> and <filename>TableRenderer.java</!
 filename>.
+									The <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> did not allow for empty <varname>columnClasses</varname> when generating columns from user input. The issue was realizing when to create numerous columns rather just one; for instance if the user input <literal>foo, </literal> with a trailing space then the expected output would be one column with the name <literal>foo</literal> and another empty column. This was not the case though, as <literal>foo, </literal> would generate just one column with <literal>foo, </literal> in its entirety as the column name, instead of splitting the columns on the comma. This behavior has now been corrected so that <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> no generates columns correctly, and in order to achieve this the following files have been updated: <filename>BasetableRenderer.java</filename>, <filename>GridRenderer.java</filename> and <filename>TableRenderer.java</f!
 ilename>.
 								</para>
 							</listitem>
 							<listitem>
@@ -976,7 +976,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									Renderer kits for <filename>faces-config.xml</filename> were processed out of order depending on if <literal>ICEfaces</literal> or <literal>Mojara 1.2_09</literal> is in use. This occured due to containing all renderer DOM nods in a list associated with a namespace. This was done so that the renderer nodes could then be processed prior to the <literal>RenderKits</literal> being created and the nodes could be processed using the proper namespace. However, by placing all the renderers into this list, we lost the document ordering. The issue has been fixed by associating the renderer nodes with their owning document and processed in the parsing order. 
+									Renderer kits for <filename>faces-config.xml</filename> were processed out of order depending on if <literal>ICEfaces</literal> or <literal>Mojara 1.2_09</literal> is in use. This occurred due to containing all renderer DOM nods in a list associated with a namespace. This was done so that the renderer nodes could then be processed prior to the <literal>RenderKits</literal> being created and the nodes could be processed using the proper namespace. However, by placing all the renderers into this list, we lost the document ordering. The issue has been fixed by associating the renderer nodes with their owning document and processed in the parsing order. 
 									
 								</para>
 							</listitem>
@@ -1004,12 +1004,12 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1099">JBPAPP-1099</ulink>: The <filename>commons-beanutils.jar</filename> file within the EAP had the incorrect version in the <filename>manifest.mf</filename> file. Through the course of correcting this bug, it was found that the <literal>beanutils</literal> component was outdated and a newer version contained manu advantages. In this update to the EAP <literal>beanutils</literal> has been upgraded to version 1.8.0, which sees the significant improvement that fixes a memory leak caused by a circular reference concerning the <classname>WeakHashMap</classname>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1099">JBPAPP-1099</ulink>: The <filename>commons-beanutils.jar</filename> file within the EAP had the incorrect version in the <filename>manifest.mf</filename> file. Through the course of correcting this bug, it was found that the <literal>beanutils</literal> component was outdated and a newer version contained many advantages. In this update to the EAP <literal>beanutils</literal> has been upgraded to version 1.8.0, which sees the significant improvement that fixes a memory leak caused by a circular reference concerning the <classname>WeakHashMap</classname>.
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1002">JBPAPP-1002</ulink>: Bean Managed Transactions (BMT) Stateful Session Beans used to be logged when transactions were not completed between invocations. However this was an error as BMT Stateful Session Beans are allowed to have this occurance and so this logging measure has been removed in this EAP update.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1002">JBPAPP-1002</ulink>: Bean Managed Transactions (BMT) Stateful Session Beans used to be logged when transactions were not completed between invocations. However this was an error as BMT Stateful Session Beans are allowed to have this occurrence and so this logging measure has been removed in this EAP update.
 						</para>
 					</listitem>
 					<listitem>
@@ -1070,7 +1070,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1286">JBPAPP-1286</ulink>: Footnotes within documentation tables and lists do not appear within PDFs. This issue resides within FOP and currently no workaround exists. Where possible footnotes are not used in the circumstances mentioned, however in documents such as the Release Notes the web address of a JIRA is automaticly generated as a footnote and places a number beside that of the JIRA, referencing a footnote that does not appear.  
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1286">JBPAPP-1286</ulink>: Footnotes within documentation tables and lists do not appear within PDFs. This issue resides within FOP and currently no workaround exists. Where possible footnotes are not used in the circumstances mentioned, however in documents such as the Release Notes the web address of a JIRA is automatically generated as a footnote and places a number beside that of the JIRA, referencing a footnote that does not appear.  
 						</para>
 					</listitem>
 				</itemizedlist>
@@ -1087,7 +1087,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1555">JBPAPP-1555</ulink>: Currently in Hibernate the SybaseDialect uses Blob and Clob where it should be set up to use image and text. Tests ataining to this currently fail with the message:
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1555">JBPAPP-1555</ulink>: Currently in Hibernate the SybaseDialect uses Blob and Clob where it should be set up to use image and text. Tests attaining to this currently fail with the message:
 						</para>
 						<screen>
 							The method com.sybase.jdbc2.jdbc.SybResultSet.getBlob(String) is not supported and should not be called.
@@ -1098,7 +1098,7 @@
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1554">JBPAPP-1554</ulink>: The <methodname>FumTest.testCompositeKeyPathExpressions()</methodname> method within Hibernate fails since Sybase currently only allows one column in a subquery select list, with the only exception to this being that a subquery in an <code>EXISTS()</code> predicate can have <code>*</code> as the select list.
 						</para>
 						<para>
-							The current workaround for this is to not use the HQL <methodname>elements()</methodname> method if the elements have a composite key. Instead the HQL should be reformated to ensure there is no subquery with more than one item in the select list.
+							The current workaround for this is to not use the HQL <methodname>elements()</methodname> method if the elements have a composite key. Instead the HQL should be reformatted to ensure there is no subquery with more than one item in the select list.
 						</para>
 					</listitem>
 					<listitem>
@@ -1119,7 +1119,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1082">JBPAPP-1082</ulink>: A limitation in the PostgreSQL JDBC driver causes a <exceptionname>javax.persistence.RollbackException</exceptionname>. This occurs when the <code>char</code> property is used without a value set as Hibernate then presists a string contaning the character <code>\u0000</code>, which causes PostgreSQL to generate an exception as it does not allow this character to be embedded in a string.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1082">JBPAPP-1082</ulink>: A limitation in the PostgreSQL JDBC driver causes a <exceptionname>javax.persistence.RollbackException</exceptionname>. This occurs when the <code>char</code> property is used without a value set as Hibernate then persists a string containing the character <code>\u0000</code>, which causes PostgreSQL to generate an exception as it does not allow this character to be embedded in a string.
 						</para>
 						<para>
 							Currently a workaround for persisting the <code>\u0000</code> character in a <code>char</code> column using PostgreSQL does not exist. Instead it is reconmended that to persist a null value for the <code>char</code> property when it is uninitialized, the <methodname>java.lang.Character</methodname> method should be used.
@@ -1132,15 +1132,15 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1068">JBPAPP-1068</ulink>: When using Microsoft SQL and <code>@Type(type="text")</code> in creating a table, the field is correctly created as <code>"text"</code> however when a delete opperation is issued the field becomes set as a <varname>varchar</varname>, forcing the Microsoft SQL driver to return the error:
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1068">JBPAPP-1068</ulink>: When using Microsoft SQL and <code>@Type(type="text")</code> in creating a table, the field is correctly created as <varname>text</varname> however when a delete operation is issued the field becomes set as a <varname>varchar</varname>, forcing the Microsoft SQL driver to return the error:
 						</para>
 						<screen>
-							The data types text and nvarchar are incompatible in the equal to operator. 
+							The data types <varname>text</varname> and <varname>varchar</varname> are incompatible in the equal to operator. 
 						</screen>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1063">JBPAPP-1063</ulink>: Currently MySQL does not support milisecond and microsecond measurements when returning database values such as <code>TIME</code> and <code>TIMESTAMP</code>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1063">JBPAPP-1063</ulink>: Currently MySQL does not support millisecond and microsecond measurements when returning database values such as <code>TIME</code> and <code>TIMESTAMP</code>.
 						</para>
 					</listitem>
 					<listitem>
@@ -1155,7 +1155,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-906">JBPAPP-906</ulink>: A bug exists within the Hibernate Core whereby the unstable synchronized Java6 <methodname>ClassLoader.loadClass</methodname> method is utilized creating a deserialized String. This causes a problem where if multiple threads are loading database rows containging arrays of strings, one thread is forced to undertake all the procedure while the other threads are left dormant.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-906">JBPAPP-906</ulink>: A bug exists within the Hibernate Core whereby the unstable synchronized Java6 <methodname>ClassLoader.loadClass</methodname> method is utilized creating a deserialized String. This causes a problem where if multiple threads are loading database rows containing arrays of strings, one thread is forced to undertake all the procedure while the other threads are left dormant.
 						</para>
 						<para>
 							The implemented workaround for this issue is to use <code>-Dsun.lang.ClassLoader.allowArraySyntax=true</code>, which can be a default setting within the <filename>run.conf</filename> file.

Modified: projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
===================================================================
--- projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml	2009-02-03 02:49:21 UTC (rev 83790)
+++ projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml	2009-02-03 03:22:20 UTC (rev 83791)
@@ -387,7 +387,7 @@
 						</listitem>
 						<listitem>
 							<para>
-								The <literal>default</literal> profile for JBoss without any reconfiguration uses the <classname>ClusteredConnectionFactory</classname> with a non-clustered post-office, however warnings would be loged about this behavior when the log messages should be reduced from a <varname>WARN</varname> level to an <varname>INFO</varname> level. The upgrade to this version of JBoss Messaging sees this implemented within the log. 
+								The <literal>default</literal> profile for JBoss without any reconfiguration uses the <classname>ClusteredConnectionFactory</classname> with a non-clustered post-office, however warnings would be logged about this behavior when the log messages should be reduced from a <varname>WARN</varname> level to an <varname>INFO</varname> level. The upgrade to this version of JBoss Messaging sees this implemented within the log. 
 							</para>
 						</listitem>
 						<listitem>
@@ -402,27 +402,27 @@
 						</listitem>
 						<listitem>
 							<para>
-								Messages which are sheduled for delivery in the future were not being removed correctly when the <methodname>removeAllMessages()</methodname> method was being called, causing the messages to bre requeued as soon as the application server or queue is restarted. <filename>ChannelSupport.java</filename> has been updated to import the <filename>TimeoutExt</filename> library in order to cast the timeout value to <filename>TimeoutExt</filename> in order to obtain the reference value via the <methodname>getTimeoutTarget()</methodname> method. With this new reference value information, the sheduled messages can be correctly removed from the queue.
+								Messages which are scheduled for delivery in the future were not being removed correctly when the <methodname>removeAllMessages()</methodname> method was being called, causing the messages to be re-queued as soon as the application server or queue is restarted. <filename>ChannelSupport.java</filename> has been updated to import the <filename>TimeoutExt</filename> library in order to cast the timeout value to <filename>TimeoutExt</filename> in order to obtain the reference value via the <methodname>get TimeoutTarget()</methodname> method. With this new reference value information, the scheduled messages can be correctly removed from the queue.
 							</para>
 						</listitem>
 						<listitem>
 							<para>
-								There was an occurance where a user may deploy a clustered queue in a single node instead of in all the nodes and the failover process would not work because of this. When this occurred an <exceptionname>IllegalStateException</exceptionname> would be generated, however this was not considered enough of a prominent warning about not deploying clustered queues correctly. <filename>MessagingPostOffice.java</filename> has now been updated to log a warning which outlies that clustered destinations must be deployed on all nodes of a cluster, instead of generating an <exceptionname>IllegalStateException</exceptionname>.
+								There was an occurrence where a user may deploy a clustered queue in a single node instead of in all the nodes and the failover process would not work because of this. When this occurred an <exceptionname>Illegal StateException</exceptionname> would be generated, however this was not considered enough of a prominent warning about not deploying clustered queues correctly. <filename>Messaging PostOffice.java</filename> has now been updated to log a warning which outlies that clustered destinations must be deployed on all nodes of a cluster, instead of generating an <exceptionname>Illegal StateException</exceptionname>.
 							</para>
 						</listitem>
 						<listitem>
 							<para>
-								The <classname>ClientAOPStackLoader</classname>, <classname>SecurityAspect.check()</classname> and <classname>ServerConnectionFactoryEndpoint</classname> needed to be able to optain TCL within a privileged block, otherwise an <exceptionname>AccessControlException</exceptionname> is produced. To fix this bug, the <methodname>setTCL</methodname>, <methodname>getTCL</methodname> and other TCL methods have been set within security blocks; this prevents access denied exceptions from <classname>ClientAOPStackLoader</classname>, <classname>SecurityAspect.check()</classname> and <classname>ServerConnectionFactoryEndpoint</classname>. 
+								The <classname>Client</classname>, <classname>SecurityAspect.check()</classname> and <classname>ServerConnection FactoryEndpoint</classname> needed to be able to obtain TLC within a privileged block, otherwise an <exceptionname>Access ControlException</exceptionname> is produced. To fix this bug, the <methodname>settle</methodname>, <methodname>gettable</methodname> and other TLC methods have been set within security blocks; this prevents access denied exceptions from <classname>Client</classname>, <classname>SecurityAspect.check()</classname> and <classname>ServerConnection FactoryEndpoint</classname>. 
 							</para>
 						</listitem>
 						<listitem>
 							<para>
-								The logging of actions within JBoss Messaging did not include the logging of messages when they are moved to the expiry or dead letter queues as this was only logged at trace level. In order to add this enhanced level of logging, the <filename>ClientConsumer.java</filename> file has been updated to log warning messages and debug information pertaining to the move of messages to the expiry or dead letter queues; <filename>ServerSessionEndpoint.java</filename> has also been updated in the same mannor. 
+								The logging of actions within JBoss Messaging did not include the logging of messages when they are moved to the expiry or dead letter queues as this was only logged at trace level. In order to add this enhanced level of logging, the <filename>ClientConsumer.java</filename> file has been updated to log warning messages and debug information pertaining to the move of messages to the expiry or dead letter queues; <filename>Server SessionEndpoint.java</filename> has also been updated in the same mannor. 
 							</para>
 						</listitem>
 						<listitem>
 							<para>
-								There was an error when a message was received under a XA tx and the JBoss Messaging XAResource is prepared but not committed, a message could be received by another consumer in another transaction while the first is still in progress. The correct behaviour is for JBoss Messaging to hold the message until the associated transaction is committed or rolled back, enabling duplication of message deliveries to be avoided. In the <filename>Delivery.java</filename> file, messages are now marked with a boolean value detailing if they are for delivery with a XA transaction and if this transaction is prepared and <filename>SimpleDelivery.java</filename> now implements this new information.
+								There was an error when a message was received under a X tx and the JBoss Messaging XAResource is prepared but not committed, a message could be received by another consumer in another transaction while the first is still in progress. The correct behavior is for JBoss Messaging to hold the message until the associated transaction is committed or rolled back, enabling duplication of message deliveries to be avoided. In the <filename>Delivery.java</filename> file, messages are now marked with a boolean value detailing if they are for delivery with a X transaction and if this transaction is prepared and <filename>SimpleDelivery.java</filename> now implements this new information.
 							</para>
 						</listitem>
 						<listitem>
@@ -432,7 +432,7 @@
 						</listitem>
 						<listitem>
 							<para>
-								There was an issue with the <classname>org.jboss.jms.server.messagecounter.MessageCounter</classname> class not being serializable as it caused an <exceptionname>UndeclaredThrowableException</exceptionname>. <filename>MessageCounter.java</filename> has been updated to now import and implement the <literal>Serializable</literal> library and be given a <varname>serialVersionUID</varname>, allowing the <classname>org.jboss.jms.server.messagecounter.MessageCounter</classname> class to be serializable.
+								There was an issue with the <classname>org.jboss.jms.server.messagecounter.MessageCounter</classname> class not being able to be serialized as it caused an <exceptionname>UndeclaredThrowableException</exceptionname>. <filename>MessageCounter.java</filename> has been updated to now import and implement the <literal>Serializable</literal> library and be given a <varname>serialVersionUID</varname>, allowing the <classname>org.jboss.jms.server.messagecounter.MessageCounter</classname> class to be serializable.
 							</para>
 						</listitem>
 						<listitem>
@@ -466,7 +466,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <classname>JDBCExtCacheLoader</classname> did not handle persistent state transfer correctly since the <methodname>JDBCExtCacheLoader.storeState()</methodname> method would use avaliable bytes on the <classname>MarshalledValueInputStream</classname> rather than on the <classname>ByteArrayInputStream</classname> when storing the persistent state. This was an issue because the <classname>MarshalledValueInputStream</classname> always returns a null value, meaning the persistent state was never written. In fixing this issue the <filename>JDBCExtendedCacheLoader.java</filename> file has been modified so that it specifies to check for avaliable space on the <classname>ByteArrayInputStream</classname>. 
+									The <classname>JDBCExtCacheLoader</classname> did not handle persistent state transfer correctly since the <methodname>JDBCExtCacheLoader.storeState()</methodname> method would use available bytes on the <classname>MarshalledValueInputStream</classname> rather than on the <classname>ByteArrayInputStream</classname> when storing the persistent state. This was an issue because the <classname>MarshalledValueInputStream</classname> always returns a null value, meaning the persistent state was never written. In fixing this issue the <filename>JDBCExtendedCacheLoader.java</filename> file has been modified so that it specifies to check for available space on the <classname>ByteArrayInputStream</classname>. 
 								</para>
 							</listitem>
 						</itemizedlist>
@@ -495,7 +495,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									A bug existed within the Remoting component by which the RemotingClassLoader would always attempt to load a class over the network first if remote classloading was enabled, leading to conflicts if the class was avaliable locally before. The code has been corrected to check locally first before looking remotely. 
+									A bug existed within the Remoting component by which the RemotingClassLoader would always attempt to load a class over the network first if remote classloading was enabled, leading to conflicts if the class was available locally before. The code has been corrected to check locally first before looking remotely. 
 								</para>
 							</listitem>
 							<listitem>
@@ -505,7 +505,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <classname>HTTPClientInvoker</classname> did not support Beginner's All-purpose Symbolic Instruction Code (BASIC) authentication for proxies when the proxy was configured through system property options of <methodname>http.proxyHost</methodname> and <methodname>http.proxyPort</methodname>. The issue appears because the <classname>HTTPClientInvoker</classname> would not check for the existence of these options and in tern it would never create a <methodname>Proxy-Authorization</methodname> request header, which is necessary for normal opperation. To fix this the <classname>HTTPClientInvoker</classname> has been modified to check for the existence of the <methodname>http.proxyHost</methodname> option and if it detects its use, creates a <methodname>Proxy-Authorization</methodname> request header.
+									The <classname>HTTPClientInvoker</classname> did not support Beginner's All-purpose Symbolic Instruction Code (BASIC) authentication for proxies when the proxy was configured through system property options of <methodname>http.proxyHost</methodname> and <methodname>http.proxyPort</methodname>. The issue appears because the <classname>HTTPClientInvoker</classname> would not check for the existence of these options and in tern it would never create a <methodname>Proxy-Authorization</methodname> request header, which is necessary for normal operation. To fix this the <classname>HTTPClientInvoker</classname> has been modified to check for the existence of the <methodname>http.proxyHost</methodname> option and if it detects its use, creates a <methodname>Proxy-Authorization</methodname> request header.
 								</para>
 							</listitem>
 							<listitem>
@@ -515,7 +515,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									Within the <classname>InvokerRegistry</classname> an error existed associated with the sequencing of events and <classname>serverLocators</classname>  would return a null on occasion. To correct this race condition, the sequencing of events within the <classname>InvokerRegistry</classname> has been rearragned so that references to <classname>transportClientFactoryClasses</classname> and <classname>clientLocators</classname> are governed by <classname>clientLock</classname> and references to <classname>transportServerFactoryClasses</classname>, <classname>serverLocators</classname>, and <classname>registeredLocators</classname> are governed by <classname>serverLock</classname>.
+									Within the <classname>InvokerRegistry</classname> an error existed associated with the sequencing of events and <classname>serverLocators</classname>  would return a null on occasion. To correct this race condition, the sequencing of events within the <classname>InvokerRegistry</classname> has been rearranged so that references to <classname>transportClientFactoryClasses</classname> and <classname>clientLocators</classname> are governed by <classname>clientLock</classname> and references to <classname>transportServerFactoryClasses</classname>, <classname>serverLocators</classname>, and <classname>registeredLocators</classname> are governed by <classname>serverLock</classname>.
 								</para>
 							</listitem>
 							<listitem>
@@ -525,12 +525,12 @@
 							</listitem>
 							<listitem>
 								<para>
-									<classname>ConnectionValidator</classname> may become unresponsive then the <methodname>run()</methodname> method is executed and utilizes the <varname>lock</varname> variable. The methods within the <methodname>run()</methodname> method are meant to time out so that the <varname>lock</varname> variable can become avaliable to the <methodname>notifyListeners()</methodname> in the event of a network failure; however <methodname>run()</methodname> may execute again before <methodname>notifyListeners()</methodname> can. The synchronization on the <varname>lock</varname> variable has been modified to avoid this issue to enable correct operation.
+									<classname>ConnectionValidator</classname> may become unresponsive then the <methodname>run()</methodname> method is executed and utilizes the <varname>lock</varname> variable. The methods within the <methodname>run()</methodname> method are meant to time out so that the <varname>lock</varname> variable can become available to the <methodname>notifyListeners()</methodname> in the event of a network failure; however <methodname>run()</methodname> may execute again before <methodname>notifyListeners()</methodname> can. The synchronization on the <varname>lock</varname> variable has been modified to avoid this issue to enable correct operation.
 								</para>
 							</listitem>
 							<listitem>
 								<para>
-									During occurances of the server being under heavy load, an <exceptionname>IllegalStateException</exceptionname> would occur within the <methodname>ConnectorValidator.run()</methodname> method because further synchronization on the <varname>lock</varname> variable was necessary. This issue was fixed during the rectification of the above problem. 
+									During occurrences of the server being under heavy load, an <exceptionname>IllegalStateException</exceptionname> would occur within the <methodname>ConnectorValidator.run()</methodname> method because further synchronization on the <varname>lock</varname> variable was necessary. This issue was fixed during the rectification of the above problem. 
 								</para>
 							</listitem>
 							<listitem>
@@ -554,7 +554,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1493">JBPAPP-1493</ulink>: An error would be shown on occassion by <emphasis>Internet Explorer</emphasis> because xml content would not be sent when <emphasis>PROPFIND</emphasis> requests were being used. This has been fixed by creating a new method within <filename>WebdavServlet.java</filename> that overrides the <methodname>DefaultServlet</methodname> implementation for servlet request processing and testing for input before launching the <methodname>DocumentBuilder</methodname>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1493">JBPAPP-1493</ulink>: An error would be shown on occasion by <emphasis>Internet Explorer</emphasis> because xml content would not be sent when <emphasis>PROPFIND</emphasis> requests were being used. This has been fixed by creating a new method within <filename>WebdavServlet.java</filename> that overrides the <methodname>DefaultServlet</methodname> implementation for servlet request processing and testing for input before launching the <methodname>DocumentBuilder</methodname>.
 						</para>
 					</listitem>
 					<listitem>
@@ -600,7 +600,7 @@
 						<itemizedlist>
 							<listitem>
 								<para>
-									When deploying JBoss Web Services within EAP without internet access, <classname>JBossWSEntityResolver</classname> would not resolve any schemas causing Web Services for Remote Portlets (WSRP) to produce an error. This issue has been fixed by modifying <classname>JBossWSEntityResolver</classname> within <filename>WSDL11Reader.java</filename> to resolve schemas locally when an internet connection is unavaliable.
+									When deploying JBoss Web Services within EAP without internet access, <classname>JBossWSEntityResolver</classname> would not resolve any schemas causing Web Services for Remote Portlets (WSRP) to produce an error. This issue has been fixed by modifying <classname>JBossWSEntityResolver</classname> within <filename>WSDL11Reader.java</filename> to resolve schemas locally when an internet connection is unavailable.
 								</para>
 							</listitem>
 							<listitem>
@@ -610,7 +610,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The component <emphasis>Xerces</emphasis> of JBoss Web Services has a feature that optimises the parsing of messages called <methodname>Deffered Node Expansion</methodname>.This defers node expansion until the nodes are accessed, improving performance where not all nodes need to be visited. However memory overheads are increased, which can be considerable for large messages. 
+									The component <emphasis>Xerces</emphasis> of JBoss Web Services has a feature that optimizes the parsing of messages called <methodname>Deffered Node Expansion</methodname>.This defers node expansion until the nodes are accessed, improving performance where not all nodes need to be visited. However memory overheads are increased, which can be considerable for large messages. 
 								</para>
 								<para>
 									This release grants the user an option to disable the <methodname>Deffered Node Expansion</methodname> feature and have all nodes expand. To achieve this the following system property needs to be set:
@@ -626,10 +626,10 @@
 							</listitem>
 							<listitem>
 								<para>
-									The end points for a <literal>transport-guarantee</literal> that is set to be confidential would see an attempt to exactly map the URL pattern in the WSDL. However since the servlet and security constrints will not be defined exactly the same a bug occured whereby JBoss Web Services would assume the <literal>transport-guarantee</literal> was not confidential when generating the address, causing the WSDL to be generated with a http address. The <literal>transport-guarantee</literal> would still be enforced by JBoss Web Services as confidential but the WSDL would contain the wrong address, leading to clients attempting to connect to an incorrect address. 
+									The end points for a <literal>transport-guarantee</literal> that is set to be confidential would see an attempt to exactly map the URL pattern in the WSDL. However since the servlet and security constraints will not be defined exactly the same a bug occurred whereby JBoss Web Services would assume the <literal>transport-guarantee</literal> was not confidential when generating the address, causing the WSDL to be generated with a http address. The <literal>transport-guarantee</literal> would still be enforced by JBoss Web Services as confidential but the WSDL would contain the wrong address, leading to clients attempting to connect to an incorrect address. 
 								</para>
 								<para>
-									In order to rectify this occurance, the <filename>MetaDataBuilder.java</filename> file has been modified so that when testing the servlet pattern it also tests correctly for the security constraint instead of assuming both with be of the same value. 
+									In order to rectify this occurrence, the <filename>MetaDataBuilder.java</filename> file has been modified so that when testing the servlet pattern it also tests correctly for the security constraint instead of assuming both with be of the same value. 
 								</para>
 							</listitem>
 							<listitem>
@@ -640,17 +640,17 @@
 							</listitem>
 							<listitem>
 								<para>
-									Deployments of JAX-WS nature would fail for JBoss AOP instrumented endpoints, generating an <exceptionname>IllegalAnnotationsException</exceptionname> as JBoss Web Services attempted to process the JBoss AOP methods. <filename>JAXWSMetaDataBuilder.java</filename> has been udpated to mark JBoss AOP methods as synthetic which allows them to be skipped. 
+									Deployments of JAX-WS nature would fail for JBoss AOP instrumented endpoints, generating an <exceptionname>IllegalAnnotationsException</exceptionname> as JBoss Web Services attempted to process the JBoss AOP methods. <filename>JAXWSMetaDataBuilder.java</filename> has been updated to mark JBoss AOP methods as synthetic which allows them to be skipped. 
 								</para>
 							</listitem>
 							<listitem>
 								<para>
-									WSDL dynamic address replacement was not working correctly in previous versions of the EAP since port and protocol numbers were not being considered. The <filename>WSDLRequestHandler.java</filename> file has been modified to use a new URL and protocol instead of the original URL and protocol in order to use the dynamicly generated port and protocol numbers. 
+									WSDL dynamic address replacement was not working correctly in previous versions of the EAP since port and protocol numbers were not being considered. The <filename>WSDLRequestHandler.java</filename> file has been modified to use a new URL and protocol instead of the original URL and protocol in order to use the dynamically generated port and protocol numbers. 
 								</para>
 							</listitem>
 							<listitem>
 								<para>
-									In converting WSDL to Java, anonymous types that are nested within anonymous types generated a JAX-RPC mapping that did not match the source. The <filename>MappingFileGeneratorHelper.java</filename> file has been corrected to ensure that the generated mapping matches the source of the informaiton. 
+									In converting WSDL to Java, anonymous types that are nested within anonymous types generated a JAX-RPC mapping that did not match the source. The <filename>MappingFileGeneratorHelper.java</filename> file has been corrected to ensure that the generated mapping matches the source of the information. 
 								</para>
 							</listitem>
 							<listitem>
@@ -689,7 +689,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP-1553</ulink>: When the <methodname>parseRequest()</methodname> method of the <classname>org.jboss.seam.web.MultipartRequest</classname> class uploaded a large file, there were occurances when this would cause an endless loop and use 100% of the computers CPU. In order to break out of the loop, a <varname>loopCounter</varname> has been implemented within the <filename>MultipartRequest.java</filename> file. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP-1553</ulink>: When the <methodname>parseRequest()</methodname> method of the <classname>org.jboss.seam.web.MultipartRequest</classname> class uploaded a large file, there were occurrences when this would cause an endless loop and use 100% of the computers CPU. In order to break out of the loop, a <varname>loopCounter</varname> has been implemented within the <filename>MultipartRequest.java</filename> file. 
 						</para>
 					</listitem>
 					<listitem>
@@ -716,7 +716,7 @@
 					<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1628</ulink>: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existance of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1628</ulink>: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existence of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection.
 						</para>
 						<para>
 							<filename>AbstractEntityPersister.java</filename> has been updated to execute a prepared statement on the result set and after calculating the <varname>propValue</varname> the result set is closed if it is not null; ensuring that no leak can occur.
@@ -759,12 +759,12 @@
 					</listitem> -->
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1519</ulink>: Sybase does not support the opperation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both opperate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1519</ulink>: Sybase does not support the operation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both operate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false.
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1496">JBPAPP-1496</ulink>: A memory leak existed because of an unclosed <emphasis>ResultSet</emphasis> when using the <emphasis>Identity</emphasis> generator option. To close the memory leak, the <emphasis>ResultSet</emphasis> is checked to make sure it is closed before returning the generated itentity value. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1496">JBPAPP-1496</ulink>: A memory leak existed because of an unclosed <emphasis>ResultSet</emphasis> when using the <emphasis>Identity</emphasis> generator option. To close the memory leak, the <emphasis>ResultSet</emphasis> is checked to make sure it is closed before returning the generated identity value. 
 						</para>
 					</listitem>
 					<listitem>
@@ -794,7 +794,7 @@
 							</listitem>
 						</itemizedlist>
 						<para>
-							To fix this isue the <filename>AbstractEntityPersister.java</filename> file was updated so that the <varname>columnNumber</varname> variable is passed to the <methodname>subclassColumnSelectableClosure</methodname> method instead of an increment of the for loop variable <varname>i</varname>.
+							To fix this issue the <filename>AbstractEntityPersister.java</filename> file was updated so that the <varname>columnNumber</varname> variable is passed to the <methodname>subclassColumnSelectableClosure</methodname> method instead of an increment of the for loop variable <varname>i</varname>.
 						</para>
 						<para>
 							<filename>CollectionTest.java</filename> has also been updated and <filename>Animal.java</filename>, <filename>Mammal.java</filename>, <filename>Zoo.hbm.xml</filename> and <filename>Zoo.java</filename> have been added for testing purposes.
@@ -802,7 +802,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1467">JBPAPP-1467</ulink>: A <exceptionname>PropertyValueException</exceptionname> would occur when merging a detached instance of a <classname>One</classname> class that contains a new <classname>Many</classname> class instance and if and only if the <classname>One</classname> class was previously loaded as a proxy during the same transaction. The files <filename>StatefulPersistenceContext.java</filename>, <filename>BackrefPropertyAccessor.java</filename>, <filename>BackrefTest.java</filename> and <filename>Child.java</filename> have been updated to check for the proxy issue in the mergining and once the proxy entity is found the <methodname>mergeMap</methodname> is updated to deal with this eventuality.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1467">JBPAPP-1467</ulink>: A <exceptionname>PropertyValueException</exceptionname> would occur when merging a detached instance of a <classname>One</classname> class that contains a new <classname>Many</classname> class instance and if and only if the <classname>One</classname> class was previously loaded as a proxy during the same transaction. The files <filename>StatefulPersistenceContext.java</filename>, <filename>BackrefPropertyAccessor.java</filename>, <filename>BackrefTest.java</filename> and <filename>Child.java</filename> have been updated to check for the proxy issue in the merging and once the proxy entity is found the <methodname>mergeMap</methodname> is updated to deal with this eventuality.
 						</para>
 					</listitem>
 					<listitem>
@@ -812,17 +812,17 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has expectly said that the version field should not be updated and does not update the field if this is the case. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has explicitly said that the version field should not be updated and does not update the field if this is the case. 
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP-1251</ulink>: Filters that were enabled for Hibernate did not apply to update and delete Hibernate Query Language (HQL) statements. In correcting this bug numerious files have been updated to ensure that the filters work correctly. This fix is related to JBPAPP-1250 below.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP-1251</ulink>: Filters that were enabled for Hibernate did not apply to update and delete Hibernate Query Language (HQL) statements. In correcting this bug numerous files have been updated to ensure that the filters work correctly. This fix is related to JBPAPP-1250 below.
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1250">JBPAPP-1250</ulink>: When creating queries with subqueries in Hibernate, any added filters would only apply to the top-level of the query and not to any subquery component or beneath. The Criteria code and HQL code asociated with this has undergone significant re-tooling to allow filters to work appropriatly with subqueries and extent as far as the Hibernate Query Language does.  
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1250">JBPAPP-1250</ulink>: When creating queries with subqueries in Hibernate, any added filters would only apply to the top-level of the query and not to any subquery component or beneath. The Criteria code and HQL code associated with this has undergone significant re-tooling to allow filters to work appropriately with subqueries and extent as far as the Hibernate Query Language does.  
 						</para>
 						<para>
 							Though this is a significant fix to Hibernate, it has been included within this CP release because of its undeniable advantage to all users and ensures that filters on queries operate how a user would expect them to.
@@ -854,7 +854,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									There were occurances when the <classname>AppServerJDBCXARecovery</classname> class would contain information to an invalid connection because of database failure. This bug was fixed with the same correction as the above issue, which is, by modifying the <classname>AppServerJDBCXARecovery</classname> class and adding the <methodname>createConnection() throws SQLException</methodname> method which makes sure a connection exists. 
+									There were occurrences when the <classname>AppServerJDBCXARecovery</classname> class would contain information to an invalid connection because of database failure. This bug was fixed with the same correction as the above issue, which is, by modifying the <classname>AppServerJDBCXARecovery</classname> class and adding the <methodname>createConnection() throws SQLException</methodname> method which makes sure a connection exists. 
 								</para>
 							</listitem>
 							<listitem>
@@ -864,7 +864,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									<methodname>TransactionImple.doOnePhaseCommit</methodname> would generate a <exceptionname>HeuristicRollbackException</exceptionname> when the commit was aborted. This meant that <methodname>XATerminatorImple.commit</methodname> was unable to distingush between a successful rollback and one in error. Fixed in this CP release, the <filename>TransactionImple.java</filename> file has been modified so that the <methodname>TransactionImple.doOnePhaseCommit</methodname> method now generates a <exceptionname>RollbackException</exceptionname> instead of a heuristic when a successful rollback is performed.
+									<methodname>TransactionImple.doOnePhaseCommit</methodname> would generate a <exceptionname>HeuristicRollbackException</exceptionname> when the commit was aborted. This meant that <methodname>XATerminatorImple.commit</methodname> was unable to distinguish between a successful rollback and one in error. Fixed in this CP release, the <filename>TransactionImple.java</filename> file has been modified so that the <methodname>TransactionImple.doOnePhaseCommit</methodname> method now generates a <exceptionname>RollbackException</exceptionname> instead of a heuristic when a successful rollback is performed.
 								</para>
 							</listitem>
 							<listitem>
@@ -898,7 +898,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1548">JBPAPP-1548</ulink>: An exploit existed within the JBoss Web Services component of the EAP that would allow anyone to view any xml file from any location if <literal>&amp;resource=path/of/an/xmlfile.xml</literal> was applied to the end of any WSDL (Web Services Definition Language) access URL. The <filename>WSDLRequestHandler.java</filename> file has been updated to only allow the parent of a WSDL file, a servers data or WSDL or overriden WSDL publish directories access to xml file resources. Additional test files are also included which were created to ensure proper opperation was being undertaken. (CVE-2009-0027 )
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1548">JBPAPP-1548</ulink>: An exploit existed within the JBoss Web Services component of the EAP that would allow anyone to view any xml file from any location if <literal>&amp;resource=path/of/an/xmlfile.xml</literal> was applied to the end of any WSDL (Web Services Definition Language) access URL. The <filename>WSDLRequestHandler.java</filename> file has been updated to only allow the parent of a WSDL file, a servers data or WSDL or overridden WSDL publish directories access to xml file resources. Additional test files are also included which were created to ensure proper operation was being undertaken. (CVE-2009-0027 )
 						</para>
 					</listitem>
 				</itemizedlist>
@@ -948,7 +948,7 @@
 						<itemizedlist>
 							<listitem>
 								<para>
-									A bug existed that would cause <filename>JacORB 2.3.0.jboss5</filename> to become unresponsive during shutdown. In rectifing this issue, the <filename>POA.java</filename> file has been modified so that instead of executing:
+									A bug existed that would cause <filename>JacORB 2.3.0.jboss5</filename> to become unresponsive during shutdown. In rectifying this issue, the <filename>POA.java</filename> file has been modified so that instead of executing:
 								</para>
 <programlisting>
 throw new org.omg.CORBA.OBJECT_NOT_EXIST();
@@ -979,7 +979,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1540">JBPAPP-1540</ulink>: Within the cluster section of the EAP, the <classname>GossipRouter</classname> and <classname>GossipClient</classname> (TCPGOSSIP) did not have socket read timeouts, socket linger timeouts and backlog set to provide the best behaviour when heavily utilized or under network situations in need of improvement. This fix provides default values and configuration options for these in order to avoid problematic situations. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1540">JBPAPP-1540</ulink>: Within the cluster section of the EAP, the <classname>GossipRouter</classname> and <classname>GossipClient</classname> (TCPGOSSIP) did not have socket read timeouts, socket linger timeouts and backlog set to provide the best behavior when heavily utilized or under network situations in need of improvement. This fix provides default values and configuration options for these in order to avoid problematic situations. 
 						</para>
 					</listitem>
 					<listitem>
@@ -994,7 +994,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1535">JBPAPP-1535</ulink>: The JDBCExtCacheLoader didn't handle persistent state transfter correctly since the <methodname>storeState</methodname> method would use avaliable space on the <classname>MarshalledValueInputStream</classname> instead of on the <classname>ByteArrayInputStream</classname>. To correct the stream usage, <filename>JDBCExtendedCacheLoader.java</filename> has been updated to store the new state using the <varname>in_stream</varname> value as long as there is space avaliable.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1535">JBPAPP-1535</ulink>: The JDBCExtCacheLoader didn't handle persistent state transfer correctly since the <methodname>storeState</methodname> method would use available space on the <classname>MarshalledValueInputStream</classname> instead of on the <classname>ByteArrayInputStream</classname>. To correct the stream usage, <filename>JDBCExtendedCacheLoader.java</filename> has been updated to store the new state using the <varname>in_stream</varname> value as long as there is space available.
 						</para>
 					</listitem>
 					<listitem>
@@ -1024,7 +1024,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <literal>Gossip Router</literal> component of JGroups provided options to set <literal>backlog</literal>, <literal>socket read timeout</literal> and <literal>socket linger timeout</literal> within the code, however these options are not avaliable via the command line. This update of the JGroups component, now includes the availability of these options to be set through the command line. 
+									The <literal>Gossip Router</literal> component of JGroups provided options to set <literal>backlog</literal>, <literal>socket read timeout</literal> and <literal>socket linger timeout</literal> within the code, however these options are not available via the command line. This update of the JGroups component, now includes the availability of these options to be set through the command line. 
 								</para>
 							</listitem>
 							<listitem>
@@ -1041,7 +1041,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1530">JBPAPP-1530</ulink>: The JCA adapter inflow did not roll back messages if a non-xa connection factory was being used within the JNDIProviderAdapter. In order to fix this issue the <filename>JmsServerSession.java</filename> file has been updated with added logic to the local transaction  seperation strategy as to allow for non-xa sessions to be rolled back using transaction session.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1530">JBPAPP-1530</ulink>: The JCA adapter inflow did not roll back messages if a non-xa connection factory was being used within the JNDIProviderAdapter. In order to fix this issue the <filename>JmsServerSession.java</filename> file has been updated with added logic to the local transaction  separation strategy as to allow for non-xa sessions to be rolled back using transaction session.
 						</para>
 					</listitem>
 					<listitem>
@@ -1059,7 +1059,7 @@
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1479">JBPAPP-1479</ulink>: Within the different distributions of the EAP that are 4.2 and 4.3, both the <filename>JBossMQ</filename> and <filename>JBoss Messaging</filename> application policies have been present within the <filename>login-config.xml</filename> file, when <filename>JBossMQ</filename> is only included in the 4.2 distribution and <filename>JBoss Messaging</filename> is similarly only included in the 4.3 distribution.
 						</para>
 						<para>
-							This has been rectified in this release by modifying <filename>build.xml</filename> and <filename>login-config.xml</filename> to differentiate between requirements for each individial distribution. 
+							This has been rectified in this release by modifying <filename>build.xml</filename> and <filename>login-config.xml</filename> to differentiate between requirements for each individual distribution. 
 						</para>
 					</listitem>
 					<listitem>
@@ -1069,12 +1069,12 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1460">JBPAPP-1460</ulink>: The JavaServer Faces (JSF) has been updated to version 1.2_10 for this EAP release. This update corrects numerious bugs and details on these fixes can be found at <ulink url="https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html">https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html</ulink>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1460">JBPAPP-1460</ulink>: The JavaServer Faces (JSF) has been updated to version 1.2_10 for this EAP release. This update corrects numerous bugs and details on these fixes can be found at <ulink url="https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html">https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/changelog.html</ulink>
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1366">JBPAPP-1366</ulink>: Creation of the EJB <filename>TIMERS</filename> table fails when the <option>Oracle</option> schema is specified. To correct this the <filename>GeneralPurposeDatabasePersistencePlugin.java</filename> file has been updated with a calling to an new <methodname>SQLUtil.fixConstraintName</methodname> function which changes all dots in a constraint name to underscores. This ensures that constraint names are compatable with Oracle.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1366">JBPAPP-1366</ulink>: Creation of the EJB <filename>TIMERS</filename> table fails when the <option>Oracle</option> schema is specified. To correct this the <filename>GeneralPurposeDatabasePersistencePlugin.java</filename> file has been updated with a calling to an new <methodname>SQLUtil.fixConstraintName</methodname> function which changes all dots in a constraint name to underscores. This ensures that constraint names are compatible with Oracle.
 						</para>
 					</listitem>
 					<listitem>
@@ -1096,12 +1096,12 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1275">JBPAPP-1275</ulink>: The Xalan part of the EAP has been upgraded from version 2.7.0 to 2.7.0.patch02. This upgrade removes the circumstance where an application which heavily used Xalan within large multi-threaded environments would encounter blocking situatinos.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1275">JBPAPP-1275</ulink>: The Xalan part of the EAP has been upgraded from version 2.7.0 to 2.7.0.patch02. This upgrade removes the circumstance where an application which heavily used Xalan within large multi-threaded environments would encounter blocking situations.
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1267">JBPAPP-1267</ulink>: <classname>UserTransaction</classname> (UT) was not able to be deployed with a clustered proxy that supported sticky transactions correctly. This has been fixed by modifying numerious files which make <classname>UserTransaction</classname> deployable with transaction sticky load balance policies. 
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1267">JBPAPP-1267</ulink>: <classname>UserTransaction</classname> (UT) was not able to be deployed with a clustered proxy that supported sticky transactions correctly. This has been fixed by modifying numerous files which make <classname>UserTransaction</classname> deployable with transaction sticky load balance policies. 
 						</para>
 					</listitem>
 					<listitem>
@@ -1111,7 +1111,7 @@
 						<itemizedlist>
 							<listitem>
 								<para>
-									A mixed EL expression ending with a  literal failed to parse as a managed bean property value. The <filename>BeanBuilder.java</filename> file was updarted with the removal of <code>ELUtils.getScope(this.expressionString, segment);</code> in order to fix this issue.
+									A mixed EL expression ending with a  literal failed to parse as a managed bean property value. The <filename>BeanBuilder.java</filename> file was updated with the removal of <code>ELUtils.getScope(this.expressionString, segment);</code> in order to fix this issue.
 								</para>
 							</listitem>
 							<listitem>
@@ -1136,7 +1136,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									An issue was present that would cause majarra to execute <filename>faces-config.xml </filename> initialization files twice, creating duplicate operations. This was caused since a record was not kept of which files had been intialized and which had not. File initialization tracking has been implemented to correct this issue and this has seen the modification of the following files: <filename>ConfigManager.java</filename>, <filename>ConfigureListener.java</filename>, <filename>WebConfiguration.java</filename>, <filename>ConfigurationResourceProvider.java</filename>, <filename>MetaInfResourceProvider.java</filename>, <filename>RIConfigResourceProvider.java</filename> and <filename>WebResourceProvider.java</filename>.
+									An issue was present that would cause majarra to execute <filename>faces-config.xml </filename> initialization files twice, creating duplicate operations. This was caused since a record was not kept of which files had been initialized and which had not. File initialization tracking has been implemented to correct this issue and this has seen the modification of the following files: <filename>ConfigManager.java</filename>, <filename>ConfigureListener.java</filename>, <filename>WebConfiguration.java</filename>, <filename>ConfigurationResourceProvider.java</filename>, <filename>MetaInfResourceProvider.java</filename>, <filename>RIConfigResourceProvider.java</filename> and <filename>WebResourceProvider.java</filename>.
 								</para>
 							</listitem>
 							<listitem>
@@ -1151,7 +1151,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									The <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> did not allow for empty <varname>columnClasses</varname> when generating columns from user unput. The issue was realizing when to create numerious columns rather just one; for instance if the user input <literal>foo, </literal> with a trailing space then the expected output would be one column with the name <literal>foo</literal> and another empty column. This was not the case though, as <literal>foo, </literal> would generate just one column with <literal>foo, </literal> in its entirety as the column name, instead of spliting the columns on the comma. This behaviour has now been corrected so that <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> no generates columns correctly, and in order to achieve this the following files have been updated: <filename>BasetableRenderer.java</filename>, <filename>GridRenderer.java</filename> and <filename>TableRenderer.java</!
 filename>.
+									The <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> did not allow for empty <varname>columnClasses</varname> when generating columns from user input. The issue was realizing when to create numerous columns rather just one; for instance if the user input <literal>foo, </literal> with a trailing space then the expected output would be one column with the name <literal>foo</literal> and another empty column. This was not the case though, as <literal>foo, </literal> would generate just one column with <literal>foo, </literal> in its entirety as the column name, instead of splitting the columns on the comma. This behavior has now been corrected so that <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> no generates columns correctly, and in order to achieve this the following files have been updated: <filename>BasetableRenderer.java</filename>, <filename>GridRenderer.java</filename> and <filename>TableRenderer.java</f!
 ilename>.
 								</para>
 							</listitem>
 							<listitem>
@@ -1175,7 +1175,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									Renderer kits for <filename>faces-config.xml</filename> were processed out of order depending on if <literal>ICEfaces</literal> or <literal>Mojara 1.2_09</literal> is in use. This occured due to containing all renderer DOM nods in a list associated with a namespace. This was done so that the renderer nodes could then be processed prior to the <literal>RenderKits</literal> being created and the nodes could be processed using the proper namespace. However, by placing all the renderers into this list, we lost the document ordering. The issue has been fixed by associating the renderer nodes with their owning document and processed in the parsing order. 
+									Renderer kits for <filename>faces-config.xml</filename> were processed out of order depending on if <literal>ICEfaces</literal> or <literal>Mojara 1.2_09</literal> is in use. This occurred due to containing all renderer DOM nods in a list associated with a namespace. This was done so that the renderer nodes could then be processed prior to the <literal>RenderKits</literal> being created and the nodes could be processed using the proper namespace. However, by placing all the renderers into this list, we lost the document ordering. The issue has been fixed by associating the renderer nodes with their owning document and processed in the parsing order. 
 
 								</para>
 							</listitem>
@@ -1203,12 +1203,12 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1099">JBPAPP-1099</ulink>: The <filename>commons-beanutils.jar</filename> file within the EAP had the incorrect version in the <filename>manifest.mf</filename> file. Through the course of correcting this bug, it was found that the <literal>beanutils</literal> component was outdated and a newer version contained manu advantages. In this update to the EAP <literal>beanutils</literal> has been upgraded to version 1.8.0, which sees the significant improvement that fixes a memory leak caused by a circular reference concerning the <classname>WeakHashMap</classname>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1099">JBPAPP-1099</ulink>: The <filename>commons-beanutils.jar</filename> file within the EAP had the incorrect version in the <filename>manifest.mf</filename> file. Through the course of correcting this bug, it was found that the <literal>beanutils</literal> component was outdated and a newer version contained many advantages. In this update to the EAP <literal>beanutils</literal> has been upgraded to version 1.8.0, which sees the significant improvement that fixes a memory leak caused by a circular reference concerning the <classname>WeakHashMap</classname>.
 						</para>
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1002">JBPAPP-1002</ulink>: Bean Managed Transactions (BMT) Stateful Session Beans used to be logged when transactions were not completed between invocations. However this was an error as BMT Stateful Session Beans are allowed to have this occurance and so this logging measure has been removed in this EAP update.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1002">JBPAPP-1002</ulink>: Bean Managed Transactions (BMT) Stateful Session Beans used to be logged when transactions were not completed between invocations. However this was an error as BMT Stateful Session Beans are allowed to have this occurrence and so this logging measure has been removed in this EAP update.
 						</para>
 					</listitem>
 					<listitem>
@@ -1269,7 +1269,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1286">JBPAPP-1286</ulink>: Footnotes within documentation tables and lists do not appear within PDFs. This issue resides within FOP and currently no workaround exists. Where possible footnotes are not used in the circumstances mentioned, however in documents such as the Release Notes the web address of a JIRA is automaticly generated as a footnote and places a number beside that of the JIRA, referencing a footnote that does not appear.  
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1286">JBPAPP-1286</ulink>: Footnotes within documentation tables and lists do not appear within PDFs. This issue resides within FOP and currently no workaround exists. Where possible footnotes are not used in the circumstances mentioned, however in documents such as the Release Notes the web address of a JIRA is automatically generated as a footnote and places a number beside that of the JIRA, referencing a footnote that does not appear.  
 						</para>
 					</listitem>
 					<listitem>
@@ -1291,7 +1291,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1555">JBPAPP-1555</ulink>: Currently in Hibernate the SybaseDialect uses Blob and Clob where it should be set up to use image and text. Tests ataining to this currently fail with the message:
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1555">JBPAPP-1555</ulink>: Currently in Hibernate the SybaseDialect uses Blob and Clob where it should be set up to use image and text. Tests attaining to this currently fail with the message:
 						</para>
 						<screen>
 							The method com.sybase.jdbc2.jdbc.SybResultSet.getBlob(String) is not supported and should not be called.
@@ -1302,7 +1302,7 @@
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1554">JBPAPP-1554</ulink>: The <methodname>FumTest.testCompositeKeyPathExpressions()</methodname> method within Hibernate fails since Sybase currently only allows one column in a subquery select list, with the only exception to this being that a subquery in an <code>EXISTS()</code> predicate can have <code>*</code> as the select list.
 						</para>
 						<para>
-							The current workaround for this is to not use the HQL <methodname>elements()</methodname> method if the elements have a composite key. Instead the HQL should be reformated to ensure there is no subquery with more than one item in the select list.
+							The current workaround for this is to not use the HQL <methodname>elements()</methodname> method if the elements have a composite key. Instead the HQL should be reformatted to ensure there is no subquery with more than one item in the select list.
 						</para>
 					</listitem>
 					<listitem>
@@ -1323,7 +1323,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1082">JBPAPP-1082</ulink>: A limitation in the PostgreSQL JDBC driver causes a <exceptionname>javax.persistence.RollbackException</exceptionname>. This occurs when the <code>char</code> property is used without a value set as Hibernate then presists a string contaning the character <code>\u0000</code>, which causes PostgreSQL to generate an exception as it does not allow this character to be embedded in a string.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1082">JBPAPP-1082</ulink>: A limitation in the PostgreSQL JDBC driver causes a <exceptionname>javax.persistence.RollbackException</exceptionname>. This occurs when the <code>char</code> property is used without a value set as Hibernate then persists a string containing the character <code>\u0000</code>, which causes PostgreSQL to generate an exception as it does not allow this character to be embedded in a string.
 						</para>
 						<para>
 							Currently a workaround for persisting the <code>\u0000</code> character in a <code>char</code> column using PostgreSQL does not exist. Instead it is reconmended that to persist a null value for the <code>char</code> property when it is uninitialized, the <methodname>java.lang.Character</methodname> method should be used.
@@ -1336,7 +1336,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1068">JBPAPP-1068</ulink>: When using Microsoft SQL and <code>@Type(type="text")</code> in creating a table, the field is correctly created as <code>"text"</code> however when a delete opperation is issued the field becomes set as a <varname>varchar</varname>, forcing the Microsoft SQL driver to return the error:
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1068">JBPAPP-1068</ulink>: When using Microsoft SQL and <code>@Type(type="text")</code> in creating a table, the field is correctly created as <code>"text"</code> however when a delete operation is issued the field becomes set as a <varname>varchar</varname>, forcing the Microsoft SQL driver to return the error:
 						</para>
 <screen>
 The data types text and nvarchar are incompatible in the equal to operator. 
@@ -1344,7 +1344,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1063">JBPAPP-1063</ulink>: Currently MySQL does not support milisecond and microsecond measurements when returning database values such as <code>TIME</code> and <code>TIMESTAMP</code>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1063">JBPAPP-1063</ulink>: Currently MySQL does not support millisecond and microsecond measurements when returning database values such as <code>TIME</code> and <code>TIMESTAMP</code>.
 						</para>
 					</listitem>
 					<listitem>
@@ -1359,7 +1359,7 @@
 					</listitem>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-906">JBPAPP-906</ulink>: A bug exists within the Hibernate Core whereby the unstable synchronized Java6 <methodname>ClassLoader.loadClass</methodname> method is utilized creating a deserialized String. This causes a problem where if multiple threads are loading database rows containging arrays of strings, one thread is forced to undertake all the procedure while the other threads are left dormant.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-906">JBPAPP-906</ulink>: A bug exists within the Hibernate Core whereby the unstable synchronized Java6 <methodname>ClassLoader.loadClass</methodname> method is utilized creating a deserialized String. This causes a problem where if multiple threads are loading database rows containing arrays of strings, one thread is forced to undertake all the procedure while the other threads are left dormant.
 						</para>
 						<para>
 							The implemented workaround for this issue is to use <code>-Dsun.lang.ClassLoader.allowArraySyntax=true</code>, which can be a default setting within the <filename>run.conf</filename> file.