From portal-commits at lists.jboss.org Wed Apr 22 10:37:09 2009
Content-Type: multipart/mixed; boundary="===============0240041369417024182=="
MIME-Version: 1.0
From: portal-commits at lists.jboss.org
To: portal-commits at lists.jboss.org
Subject: [portal-commits] JBoss Portal SVN: r13261 -
 docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US.
Date: Wed, 22 Apr 2009 10:37:09 -0400
Message-ID: <E1LwdZV-0008KC-9h@committer01.frg.pub.inap.atl.jboss.com>

--===============0240041369417024182==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Author: prabhat.jha(a)jboss.com
Date: 2009-04-22 10:37:09 -0400 (Wed, 22 Apr 2009)
New Revision: 13261

Added:
   docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-U=
S/Release_Notes.ent
   docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-U=
S/Release_Notes.xml
Modified:
   docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-U=
S/Book_Info.xml
Log:
update identity version and some minor versioning fix

Modified: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_=
Me/en-US/Book_Info.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-=
US/Book_Info.xml	2009-04-22 12:16:09 UTC (rev 13260)
+++ docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-=
US/Book_Info.xml	2009-04-22 14:37:09 UTC (rev 13261)
@@ -3,8 +3,8 @@
 ]>
 =

 <articleinfo>
-	<title>Release Notes GA</title>
-	<subtitle>for Use with JBoss Enterprise Portal Platform 4.3</subtitle>
+	<title>Release Notes</title>
+	<subtitle></subtitle>
 	<edition>1.0</edition>
 	<pubsnumber>6</pubsnumber>
 	<productname>JBoss Enterprise Portal Platform</productname>

Added: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/=
en-US/Release_Notes.ent
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-=
US/Release_Notes.ent	                        (rev 0)
+++ docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-=
US/Release_Notes.ent	2009-04-22 14:37:09 UTC (rev 13261)
@@ -0,0 +1,3 @@
+<!ENTITY HOLDER "Red Hat, Inc">
+<!ENTITY YEAR "2008">
+<!ENTITY VERSION "4.3 CP01">

Added: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/=
en-US/Release_Notes.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-=
US/Release_Notes.xml	                        (rev 0)
+++ docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-=
US/Release_Notes.xml	2009-04-22 14:37:09 UTC (rev 13261)
@@ -0,0 +1,873 @@
+<?xml version=3D"1.0"?>
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.=
oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+<!ENTITY % RH_ENTITIES SYSTEM "./Common_Config/rh-entities.ent">
+%RH_ENTITIES;
+]>
+<article id=3D"JBEAP-Release-Notes">
+	<xi:include xmlns:xi=3D"http://www.w3.org/2001/XInclude" href=3D"Book_Inf=
o.xml"/>
+	<section id=3D"Introduction">
+		<title>
+			Introduction
+		</title>
+		<para>
+			These release notes contain important information related to JBoss Ente=
rprise Portal Platform &VERSION;. New features, known problems, resources, =
and other current issues are addressed here.
+		</para>
+		<section id=3D"Overview">
+			<title>Overview</title>
+ 			<para>
+                                JBoss Enterprise Portal Platform facilitat=
es the delivery of web-based composite applications and high-performance we=
b presences. Through its agile, reusable framework, customers can minimize =
the cost and complexity of their web infrastructures. Its use of open stand=
ards mitigates the risk of vendor lock-in, ensuring compatibility. As an in=
tegral component of JBoss Enterprise Middleware, the large and vibrant JBos=
s.org developer community fosters its continued innovation and enterprise q=
uality. And it's deployed on JBoss Enterprise Application Platform=E2=80=94=
the industry=E2=80=99s #1 J2EE-certified application platform ensuring perf=
ormance, scalability, and a reliable and straightforward path to implementa=
tion. =

+                        </para>
+                        <para>
+JBoss Enterprise Application Platform is the next evolutionary step in ope=
n source enterprise software. It is a powerful tool for developing rich, hi=
gh performance, Web 2.0 applications on a pure Java Platform.
+			</para>
+			<para>
+				JBoss Enterprise Application Platform provides complete compatibility =
with existing J2EE 1.4 enterprise Java applications. At the same time, almo=
st all the key features and components defined in the Java EE 5.0 specifica=
tion are supported. So your new enterprise Java applications can take immed=
iate advantage of the Java EE 5.0's significantly simpler POJO-based progra=
mming model.
+			</para>
+			<para>
+				Further, by integrating best-of-breed open source frameworks such as J=
Boss Seam, Hibernate, Tomcat, and JBoss Cache the Platform takes advantage =
of innovations in the open source community. As well, JBoss Enterprise Appl=
ication Platform is fully tested and supported by Red Hat, and is certified=
 to work on many leading enterprise hardware and software products.
+			</para>
+			<para>
+				All of which means you can develop your new application taking advanta=
ge of Java EE 5.0 technologies immediately and with the confidence of knowi=
ng it will remain forward-compatible with future versions of the JBoss Plat=
form.
+			</para>
+		</section>
+	</section>
+	<section id=3D"New_Features">
+		<title>New Features in JBoss Enterprise Portal Platform 4.3</title>
+		<section id=3D"JSR-286">
+			<title>Portlet 2.0 -JSR 286</title>
+			<para>
+				The main improvement of the Enterprise Portal Platform is the support =
of Portlet 2.0 specification which enables Inter Portlet Communication by s=
haring parameters and event support.
+			</para>
+		</section>
+	</section>
+	<section id=3D"Component_Versions">
+		<title>Component Versions</title>
+		<para>
+			This section details the versions of the components which create the En=
terprise Portal Platform 4.3 that can be found in release on top of the com=
ponents delivered by the Enterprise Application Platform 4.3.CP04. =

+		</para>
+		<itemizedlist>
+			<listitem>
+				<para>
+					Identity Module 1.1.0
+				</para>
+			</listitem>
+			<listitem>
+				<para>
+					Common Module 1.2.4
+				</para>
+			</listitem>
+			<listitem>
+				<para>
+					Portlet Module 2.0.7
+				</para>
+			</listitem>
+			<listitem>
+				<para>
+					Web Module 1.2.3
+				</para>
+			</listitem>
+			 <listitem>
+                                <para>
+                                        CMS Module 1.2.5
+                                </para>
+                        </listitem>
+
+			<listitem>
+				<para>
+					JBoss Portlet Bridge 1.0.0.CR1
+				</para>
+			</listitem>
+		</itemizedlist>
+		<note>
+			<para>
+				The Enterprise Portal Platform Server has been redefined for the enter=
prise market to a level where direct association to a community release can=
 no longer be drawn.
+			</para>
+		</note>
+	</section>
+	<section id=3D"Product-Support-and-License-Links">
+		<title>
+			Product Support and License Website Links
+		</title>		=

+			<formalpara>
+				<title>Support Processes</title>
+				<para>
+					<ulink url=3D"http://www.redhat.com/support/process/">http://www.redh=
at.com/support/process/</ulink>
+				</para>
+			</formalpara>
+				=

+			<formalpara>
+				<title>
+					Production Support Scope of Coverage
+				</title>
+				<para>
+					<ulink url=3D"http://www.redhat.com/support/policy/soc/production">ht=
tp://www.redhat.com/support/policy/soc/production</ulink>
+				</para>
+			</formalpara>
+				=

+				=

+			<formalpara>
+				<title>
+					Production Support Service Level Agreement
+				</title>
+				=

+				<para>
+					<ulink url=3D"http://www.redhat.com/support/policy/sla/production/">h=
ttp://www.redhat.com/support/policy/sla/production/</ulink>
+				</para>
+			</formalpara>
+			=

+			<formalpara>
+				<title>
+					Developer Support Scope of Coverage
+				</title>
+				=

+				<para>
+					<ulink url=3D"http://www.redhat.com/support/policy/soc/developer/">ht=
tp://www.redhat.com/support/policy/soc/developer/</ulink>
+				</para>
+			</formalpara>
+				=

+			<formalpara>
+				<title>
+					Developer Support Service Level Agreement
+				</title>
+				=

+				<para>
+					<ulink url=3D"http://www.redhat.com/support/policy/sla/developer/">ht=
tp://www.redhat.com/support/policy/sla/developer/</ulink>
+				</para>
+			</formalpara>
+				=

+			<formalpara>
+				<title>
+					Product Update and Support Policy by Product
+				</title>
+				=

+				<para>
+					<ulink url=3D"http://www.redhat.com/security/updates/jboss_notes/">ht=
tp://www.redhat.com/security/updates/jboss_notes/</ulink>
+				</para>
+			</formalpara>
+			=

+			<formalpara>
+				<title>
+					JBoss End User License Agreement
+				</title>
+				=

+				<para>
+					<ulink url=3D"http://www.redhat.com/licenses/jboss_eula.html">http://=
www.redhat.com/licenses/jboss_eula.html</ulink>
+				</para>
+			</formalpara>
+		</section>
+<!--
+	<section id=3D"Issues-fixed-in-this-release">
+		<title>
+			Issues fixed in this release
+		</title>
+		=

+		<para>
+			Following is a list of issues fixed in this release:
+		</para>
+		<formalpara>
+			<title>JBoss Messaging</title>
+			<para>
+			<itemizedlist>
+				<listitem>
+					<para>
+						<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1615">JBPAPP-=
1615</ulink>: The JBoss Messaging component of the EAP has been upgraded to=
 version 1.4.0.SP3-CP05. A list of the included fixes is as follows:
+					</para>
+					<itemizedlist>
+						<listitem>
+							<para>
+								The <literal>default</literal> profile for JBoss without any recon=
figuration uses the <classname>ClusteredConnectionFactory</classname> with =
a non-clustered post-office, however warnings would be loged about this beh=
avior 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>
+							<para>
+								<classname>ClusterViewUpdateTest</classname> was broken and did no=
t work correctly in previous releases with the cause being that the expecte=
d time until failure detection for some clustering tests was too long. In o=
rder to correct this the values for <varname>validatorPingPeriod</varname> =
and <varname>validatorPingTimeout</varname> have been changed to be 2 secon=
ds each, combining to 4 seconds as the total time until expected failure de=
tection.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								Client connection parameters were not passed to the JBoss Remoting=
 layer, forcing Remoting to use default values instead of user configured v=
alues. In order to use the correct values, <filename>JMSRemotingConnection.=
java</filename> has been updated so that the <methodname>Client.addConnecti=
onListener</methodname> method is used with <varname>listener</varname> and=
 <varname>serverLocator.gerParameters()</varname> as parameters.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								Messages which are sheduled for delivery in the future were not be=
ing removed correctly when the <methodname>removeAllMessages()</methodname>=
 method was being called, causing the messages to bre requeued as soon as t=
he application server or queue is restarted. <filename>ChannelSupport.java<=
/filename> has been updated to import the <filename>TimeoutExt</filename> l=
ibrary in order to cast the timeout value to <filename>TimeoutExt</filename=
> in order to obtain the reference value via the <methodname>getTimeoutTarg=
et()</methodname> method. With this new reference value information, the sh=
eduled messages can be correctly removed from the queue.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								There was an occurance where a user may deploy a clustered queue i=
n a single node instead of in all the nodes and the failover process would =
not work because of this. When this occurred an <exceptionname>IllegalState=
Exception</exceptionname> would be generated, however this was not consider=
ed enough of a prominent warning about not deploying clustered queues corre=
ctly. <filename>MessagingPostOffice.java</filename> has now been updated to=
 log a warning which outlies that clustered destinations must be deployed o=
n all nodes of a cluster, instead of generating an <exceptionname>IllegalSt=
ateException</exceptionname>.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								The <classname>ClientAOPStackLoader</classname>, <classname>Securi=
tyAspect.check()</classname> and <classname>ServerConnectionFactoryEndpoint=
</classname> needed to be able to optain TCL within a privileged block, oth=
erwise 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; th=
is prevents access denied exceptions from <classname>ClientAOPStackLoader</=
classname>, <classname>SecurityAspect.check()</classname> and <classname>Se=
rverConnectionFactoryEndpoint</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 leve=
l of logging, the <filename>ClientConsumer.java</filename> file has been up=
dated to log warning messages and debug information pertaining to the move =
of messages to the expiry or dead letter queues; <filename>ServerSessionEnd=
point.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 t=
he JBoss Messaging XAResource is prepared but not committed, a message coul=
d be received by another consumer in another transaction while the first is=
 still in progress. The correct behaviour is for JBoss Messaging to hold th=
e message until the associated transaction is committed or rolled back, ena=
bling duplication of message deliveries to be avoided. In the <filename>Del=
ivery.java</filename> file, messages are now marked with a boolean value de=
tailing if they are for delivery with a XA transaction and if this transact=
ion is prepared and <filename>SimpleDelivery.java</filename> now implements=
 this new information.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								The <methodname>shutdownNow()</methodname> method was not synchron=
ized and may cause a <exceptionname>NoSuchElementException</exceptionname> =
during runtime as a result. A synchronization block has been placed around =
the <methodname>shutdownNow()</methodname> code within <filename>OrderedExe=
cutorFactory.java</filename>.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								There was an issue with the <classname>org.jboss.jms.server.messag=
ecounter.MessageCounter</classname> class not being serializable as it caus=
ed an <exceptionname>UndeclaredThrowableException</exceptionname>. <filenam=
e>MessageCounter.java</filename> has been updated to now import and impleme=
nt the <literal>Serializable</literal> library and be given a <varname>seri=
alVersionUID</varname>, allowing the <classname>org.jboss.jms.server.messag=
ecounter.MessageCounter</classname> class to be serializable.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								When the methods <methodname>unregisterSucker()</methodname> or <m=
ethodname>registerSucker()</methodname> was called a <exceptionname>Concurr=
entModificationException</exceptionname> would be generated by the time the=
 <literal>HashSet</literal> containing the <literal>suckers</literal> was i=
terated. The issue would present itself on clusters with a magnitude of nod=
es (for instance it appeared on a 8 node cluster but not a 4 node cluster).=
 This bug was corrected by creating an iterator that used a private set of =
<literal>suckers</literal> for iteration through the <literal>HashSet</lite=
ral> of <literal>suckers</literal> in order to avoid the exception.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								The bridge within JBoss Messaging would only retry connection crea=
tion to a remote destination after startup and if the remote provider was n=
ot available at startup, the bridge would fail to start. The <filename>Brid=
ge.java</filename> and <filename>BridgeService.java</filename> files have u=
ndergone extensive modification and now the <literal>factory</literal> is s=
et to the <literal>bridge</literal> which undertakes the lookup itself inst=
ead of looking up the destinations.
+							</para>
+						</listitem>
+					</itemizedlist>
+				</listitem>
+			</itemizedlist>
+			</para>
+		</formalpara>
+		<formalpara>
+			<title>JBoss Cache</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1533">JBPAPP=
-1533</ulink>: The JBoss Cache component of the EAP has been upgraded to ve=
rsion 1.4.1.SP11. A list of the included fixes is as follows:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									The <classname>JDBCCacheLoader</classname> implementation did not=
 work with Sybase as it would try to set a null <varname>BLOB</varname> col=
umn which is unsupported within Sybase. To correct this the <filename>JDBCC=
acheLoader.java</filename> file has been updated so that the Sybase Driver =
sets a null <varname>LONGVARBINARY</varname> value, allowing the <classname=
>JDBCCacheLoader</classname> implementation to work correctly.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>JDBCExtCacheLoader</classname> did not handle pers=
istent state transfer correctly since the <methodname>JDBCExtCacheLoader.st=
oreState()</methodname> method would use avaliable bytes on the <classname>=
MarshalledValueInputStream</classname> rather than on the <classname>ByteAr=
rayInputStream</classname> when storing the persistent state. This was an i=
ssue because the <classname>MarshalledValueInputStream</classname> always r=
eturns a null value, meaning the persistent state was never written. In fix=
ing this issue the <filename>JDBCExtendedCacheLoader.java</filename> file h=
as been modified so that it specifies to check for avaliable space on the <=
classname>ByteArrayInputStream</classname>. =

+								</para>
+							</listitem>
+						</itemizedlist>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</formalpara>
+		<formalpara>
+			<title>JBoss Remoting</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1531">JBPAPP=
-1531</ulink>: The JBoss Remoting component of the EAP has been upgraded to=
 version 2.2.2.SP11. A list of the included fixes is as follows:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									The <methodname>ConnectionValidator.run()</methodname> method had=
 the ability to be called by a user before the private method <methodname>C=
onnectionValidator.start()</methodname> was called, resulting in the <varna=
me>clientInvoker</varname> and <varname>timer</varname> fields being set to=
 null and generating a <exceptionname>NullPointerException</exceptionname>.=
 Within the <filename>ConnectionValidator.java</filename> file the fields a=
re now checked to see if they are null upon execution of the <methodname>Co=
nnectionValidator.run()</methodname> method, one or both are then an <excep=
tionname>IllegalStateException</exceptionname> is displayed to the user out=
lining that <methodname>ConnectionValidator.run()</methodname> should not b=
e called directly but <methodname>addConnectionListener()</methodname> shou=
ld be used instead.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									Two bugs existed within the <methodname>org.jboss.remoting.marsha=
l.MarshallerLoaderHandler.loadClassBytes()</methodname> method that prohibi=
ted remote classloading to work correctly with isolated EARs. The first was=
 that a while loop in the code needed a break and the second was that the c=
all to the <methodname>org.jboss.mx.loading.LoaderRepository.getCachedClass=
()</methodname> method should have been a general call to <methodname>Loade=
rRepository.loadClass()</methodname>. These two issues have been rectified =
with this Remoting update, allowing remote classloading to function correct=
ly.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									A bug existed within the Remoting component by which the Remoting=
ClassLoader would always attempt to load a class over the network first if =
remote classloading was enabled, leading to conflicts if the class was aval=
iable locally before. The code has been corrected to check locally first be=
fore looking remotely. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>ServerInvokerCallbackHandler</classname> class wou=
ld become unresponsive when calling the <methodname>BlockingCallbackStore.a=
dd()</methodname> method after locking the callback field with a true respo=
nce from the <methodname>persistCallback()</methodname> method. This would =
occur because the <methodname>BlockingCallbackStore.getNext()</methodname> =
needed to control the lock on the callback field to break the waiting perio=
d, however this could not be achieved because of the wait period. To fix th=
is issue the call to the <methodname>BlockingCallbackStore.add()</methodnam=
e> method has been removed as it was an unnecessary step. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>HTTPClientInvoker</classname> did not support Begi=
nner's All-purpose Symbolic Instruction Code (BASIC) authentication for pro=
xies when the proxy was configured through system property options of <meth=
odname>http.proxyHost</methodname> and <methodname>http.proxyPort</methodna=
me>. The issue appears because the <classname>HTTPClientInvoker</classname>=
 would not check for the existence of these options and in tern it would ne=
ver create a <methodname>Proxy-Authorization</methodname> request header, w=
hich is necessary for normal opperation. To fix this the <classname>HTTPCli=
entInvoker</classname> has been modified to check for the existence of the =
<methodname>http.proxyHost</methodname> option and if it detects its use, c=
reates a <methodname>Proxy-Authorization</methodname> request header.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<classname>HTTPClientInvoker</classname> would generate a <except=
ionname>NullPointerException</exceptionname> when the HTTP server returned =
an error code without any content and then the <methodname>java.net.HttpUrl=
Connection.getInputStream()</methodname> method returned a null value. In o=
rder to improve control over this behavior, the new variable <varname>UNMAR=
SHAL_NULL_STREAM</varname> has been added to the <classname>HTTPClientInvok=
er</classname>. If this variable is set to true (the default value) the def=
ault behavior is executed, however if it is set to false the call to the <m=
ethodname>UnMarshaller.read()</methodname> is skipped.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									Within the <classname>InvokerRegistry</classname> an error existe=
d associated with the sequencing of events and <classname>serverLocators</c=
lassname>  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>transportClientFactor=
yClasses</classname> and <classname>clientLocators</classname> are governed=
 by <classname>clientLock</classname> and references to <classname>transpor=
tServerFactoryClasses</classname>, <classname>serverLocators</classname>, a=
nd <classname>registeredLocators</classname> are governed by <classname>ser=
verLock</classname>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									A bug existed where the value in the client configuration map of =
the <classname>ConnectionValidator</classname> would be ignored when the ov=
erloaded <methodname>org.jboss.remoting.Client</methodname> method was call=
ed and the <varname>DEFAULT_PING_PERIOD</varname> variable value was placed=
 into the metadata map passed to the <classname>ConnectionValidator</classn=
ame>. This has been corrected by updating <classname>org.jboss.remoting.Cli=
ent.addConnectionListener</classname> so that <varname>DEFAULT_PING_PERIOD<=
/varname> is only passed if the value of <varname>VALIDATOR_PING_PERIOD</va=
rname> within the client's configuration map has not been set. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<classname>ConnectionValidator</classname> may become unresponsiv=
e then the <methodname>run()</methodname> method is executed and utilizes t=
he <varname>lock</varname> variable. The methods within the <methodname>run=
()</methodname> method are meant to time out so that the <varname>lock</var=
name> variable can become avaliable to the <methodname>notifyListeners()</m=
ethodname> in the event of a network failure; however <methodname>run()</me=
thodname> may execute again before <methodname>notifyListeners()</methodnam=
e> can. The synchronization on the <varname>lock</varname> variable has bee=
n modified to avoid this issue to enable correct operation.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									During occurances of the server being under heavy load, an <excep=
tionname>IllegalStateException</exceptionname> would occur within the <meth=
odname>ConnectorValidator.run()</methodname> method because further synchro=
nization on the <varname>lock</varname> variable was necessary. This issue =
was fixed during the rectification of the above problem. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									A synchronization error within the <classname>MarshalFactory</cla=
ssname> was allowing a subsystem to add a marshaller at the same time as EJ=
B3 was trying to extract one causing users to receive an <exceptionname>Inv=
alidMarshallingResource</exceptionname> exception; this also applied to unm=
arshallers. The error has been fixed by updating the <filename>jboss-remoti=
ng.jar</filename> file to include synchronized static Maps within the <clas=
sname>MarshalFactory</classname>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>SocketServerInvoker</classname> had an issue when =
shutting down <varname>ServerThreads</varname> causing a user to possibly r=
eceive an invocation to a closed <classname>SocketServerInvoker</classname>=
 on the client side, causing an <exceptionname>InvalidStateException</excep=
tionname>. Allowing this exception would cause a clustered EJB3 system to g=
enerate a <exceptionname>UndeclaredThrowableException</exceptionname> inste=
ad of trying alternative servers. To allow for alternatives to be attempted=
, an optional behavior of allowing the <classname>MicroRemoteClientInvoker<=
/classname> to interpret an <exceptionname>InvalidStateException</exception=
name> as a <exceptionname>CannotConnectException</exceptionname>, allowing =
for other servers to be attempted.
+								</para>
+							</listitem>
+						</itemizedlist>
+					</listitem>
+				</itemizedlist> =

+			</para>
+		</formalpara>
+		<formalpara>
+			<title>JBoss Web</title>
+				<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1493">JBPAPP=
-1493</ulink>: An error would be shown on occassion by <emphasis>Internet E=
xplorer</emphasis> because xml content would not be sent when <emphasis>PRO=
PFIND</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 requ=
est processing and testing for input before launching the <methodname>Docum=
entBuilder</methodname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1470">JBPAPP=
-1470</ulink>: When using APR (Apache Portable Runtime) on any operating sy=
stem other than those which use the Linux Kernal 2.4 or newer, the <paramet=
er>deferAccept</parameter> option would be set to false in the <methodname>=
AprEndpoint</methodname>. This may lead to a <exceptionname>NullPointerExce=
ption</exceptionname> as the <methodname>accepter</methodname> thread start=
s to process a request while also calling for a <methodname>poller</methodn=
ame> before initialization. The issue has been resolved by moving the <meth=
odname>acceptor</methodname> threads to being executed last when starting t=
he <methodname>AprEndpoint</methodname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1334">JBPAPP=
-1334</ulink>: The JBoss Web component of the EAP has been upgraded to vers=
ion 2.0.0-6.CP09. A list of the included fixes is as follows:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									If a war deployment included its own version of <filename>xalan.j=
ar</filename> and <filename>xercesImpl.jar</filename> in <filename>WEB-INF/=
lib</filename>, the JBossWeb servlet container classloader returns JBoss pr=
ovided version of the <literal>SAXParser</literal> from <methodname>SAXPars=
erFactory.newInstance().newSAXParser()</methodname> rather than the version=
 provided in the war deployment. To fix this bug the <filename>WebAppClassL=
oader.java</filename> has been updated to ensure the correct parser is used.
+						</para>
+							</listitem>
+						</itemizedlist>
+					</listitem>
+				</itemizedlist> =

+				</para>
+		</formalpara>
+		<formalpara>
+			<title>JBoss Web Services</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1552">JBPAPP=
-1552</ulink>: When deploying JBoss Web Services within EAP without interne=
t access, <classname>JBossWSEntityResolver</classname> would not resolve an=
y schemas causing Web Services for Remote Portlets (WSRP) to produce an err=
or. This issue has been fixed by modifying <classname>JBossWSEntityResolver=
</classname> within <filename>WSDL11Reader.java</filename> to resolve schem=
as locally when an internet connection is unavaliable.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1449">JBPAPP=
-1449</ulink>: WSProvide would ignore a <literal>SOAPBinding</literal> decl=
aration specified in the EJB3 stateless session bean. To correct this and a=
llow <literal>SOAPBinding</literal> to work as expected the following files=
 have been modified: <filename>WSDLGenerator.java</filename>, <filename>SOA=
PEndpoint.java</filename>, <filename>Constants.java</filename>, <filename>W=
SDLWriter.java</filename>, <filename>SOAPBindingTestCase.java</filename> an=
d <filename>WSDL11Writer.java</filename>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1439">JBPAPP=
-1439</ulink>: The component <emphasis>Xerces</emphasis> of JBoss Web Servi=
ces 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 vi=
sited. However memory overheads are increased, which can be considerable fo=
r large messages. =

+						</para>
+						<para>
+							This release grants the user an option to disable the <methodname>D=
effered Node Expansion</methodname> feature and have all nodes expand. To a=
chieve this the following system property needs to be set:
+						</para>
+<programlisting>
+-Dorg.jboss.ws.disable_deferred_node_expansion=3Dtrue
+</programlisting>
+					</listitem>
+				</itemizedlist> =

+			</para>
+		</formalpara> =

+		<formalpara>
+			<title>JBoss Seam</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP=
-1553</ulink>: When the <methodname>parseRequest()</methodname> method of t=
he <classname>org.jboss.seam.web.MultipartRequest</classname> class uploade=
d 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 <v=
arname>loopCounter</varname> has been implemented within the <filename>Mult=
ipartRequest.java</filename> file. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1494">JBPAPP=
-1494</ulink>: The portal example that was previously included with the Sea=
m EAP distribution has been removed in order to avoid confusion that Seam 1=
.2.1 included with the EAP supports portal. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1044">JBPAPP=
-1044</ulink>: After basic interaction with the Seam examples <filename>cha=
troom</filename>, <filename>mail</filename>, <filename>registration</filena=
me>, <filename>booking</filename> and <filename>dvdstore</filename> would g=
enerate a <exceptionname>NullPointerException</exceptionname> during undepl=
oyment. In correcting this issue, the <filename>RootInterceptor.java</filen=
ame> file was updated to check if an applications context still active upon=
 undeployment and deal with this appropriately.
+						</para>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</formalpara>
+		<formalpara>
+			<title>JBoss Hibernate</title>
+			<para>
+				<itemizedlist>
+					<important>
+						<para>
+							Hibernate Core has been updated to an enhanced 3.2.4.sp1.cp07 versi=
on. The following issues represent the changes for this version.
+						</para>
+					</important>
+					<listitem>
+						<para>
+							<ulink url=3D"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>sta=
tementsToClose</classname> collection instead of closing it unconditionally=
. This has now caused a properties leak as the <methodname>org.hibernate.pe=
rsister.entity.AbstractEntityPersister#processGeneratedProperties()</method=
name> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStateme=
nt()</methodname> and the statement within <methodname>org.hibernate.persis=
ter.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; e=
nsuring that no leak can occur.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1582">JBPAPP=
-1582</ulink>:  =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1524">JBPAPP=
-1524</ulink>: The Sybase functions <methodname>second()</methodname>, <met=
hodname>minute()</methodname>, <methodname>hour()</methodname> and <methodn=
ame>extract()</methodname> caused a <exceptionname>GenericJDBCException</ex=
ceptionname> when used. Moving these functions from the <filename>SQLServer=
Dialect.java</filename> file to the <filename>SybaseDialect.java</filename>=
 file allows for these functions to work correctly.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"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 co=
rrectly the <filename>SQLServerDialect.java</filename> file has been update=
d to include a new <methodname>supportsCascadeDelete()</methodname> method =
which returns true and <filename>SybaseDialect.java</filename> has been upd=
ated to include a new <methodname>supportsCascadeDelete()</methodname> meth=
od which returns false.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1496">JBPAPP=
-1496</ulink>: A memory leak existed because of an unclosed <emphasis>Resul=
tSet</emphasis> when using the <emphasis>Identity</emphasis> generator opti=
on. To close the memory leak, the <emphasis>ResultSet</emphasis> is checked=
 to make sure it is closed before returning the generated itentity value. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1480">JBPAPP=
-1480</ulink>: Hibernate would attempt to read from an invalid column in th=
e collection result set when the following conditions were present:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									Instances of a subclass were contained in a collection.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The subclasses were single-table and used a &lt;join&gt; (table-p=
er-subclass with discriminator).
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The &lt;join&gt; portion of the subclass contained at least 3 of =
its own columns.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The &lt;join&gt; tables were fetched by select and not the defaul=
t method for this task.
+								</para>
+							</listitem>
+						</itemizedlist>
+						<para>
+							To fix this isue the <filename>AbstractEntityPersister.java</filena=
me> file was updated so that the <varname>columnNumber</varname> variable i=
s passed to the <methodname>subclassColumnSelectableClosure</methodname> me=
thod 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>, <filena=
me>Zoo.hbm.xml</filename> and <filename>Zoo.java</filename> have been added=
 for testing purposes.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1467">JBPAPP=
-1467</ulink>: A <exceptionname>PropertyValueException</exceptionname> woul=
d occur when merging a detached instance of a <classname>One</classname> cl=
ass that contains a new <classname>Many</classname> class instance and if a=
nd only if the <classname>One</classname> class was previously loaded as a =
proxy during the same transaction. The files <filename>StatefulPersistenceC=
ontext.java</filename>, <filename>BackrefPropertyAccessor.java</filename>, =
<filename>BackrefTest.java</filename> and <filename>Child.java</filename> h=
ave 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.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1365">JBPAPP=
-1365</ulink>: A bug existed within Hibernate Core where the <methodname>ad=
dDuplicateAlias</methodname> method would include an entry into the hash ma=
p even when the <varname>classAlias</varname> variable was set to null; cau=
sing a <exceptionname>NullPointerException</exceptionname> when the <method=
name>CrazyJPARRequirements()</methodname> method is called. To correct this=
 issue the <filename>FromClause.java</filename> file has been modified to c=
orrect the <methodname>addDuplicateAlias</methodname> method by testing if =
the <varname>alias</varname> variable is null and if it is not null then th=
e <methodname>fromElementByClassAlias.put</methodname> is now called, inste=
ad of this method being called even if <varname>alias</varname> contained a=
 null value.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP=
-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generat=
e SQL and the version field is specified by the user to not be updated, the=
 <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> meth=
od would still update the field causing exceptions to appear in certain cas=
es. Within this EAP update <filename>AbstractEntityPersister.java</filename=
> has been corrected to check if the user has expectly said that the versio=
n field should not be updated and does not update the field if this is the =
case. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP=
-1251</ulink>: Filters that were enabled for Hibernate did not apply to upd=
ate and delete Hibernate Query Language (HQL) statements. In correcting thi=
s bug numerious files have been updated to ensure that the filters work cor=
rectly. This fix is related to JBPAPP-1250 below.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1250">JBPAPP=
-1250</ulink>: When creating queries with subqueries in Hibernate, any adde=
d filters would only apply to the top-level of the query and not to any sub=
query component or beneath. The Criteria code and HQL code asociated with t=
his has undergone significant re-tooling to allow filters to work appropria=
tly 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 an=
d ensures that filters on queries operate how a user would expect them to.
+						</para>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</formalpara>
+		<formalpara>
+			<title>Security Issues</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1548">JBPAPP=
-1548</ulink>: An exploit existed within the JBoss Web Services component o=
f the EAP that would allow anyone to view any xml file from any location if=
 <literal>&amp;resource=3Dpath/of/an/xmlfile.xml</literal> was applied to t=
he end of any WSDL (Web Services Definition Language) access URL. The <file=
name>WSDLRequestHandler.java</filename> file has been updated to only allow=
 the parent of a WSDL file, a servers data or WSDL or overriden WSDL publis=
h directories access to xml file resources. Additional test files are also =
included which were created to ensure proper opperation was being undertake=
n. (CVE-2009-0027 )
+						</para>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</formalpara>
+		<formalpara>
+			<title>Documentation</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+						</para> =

+					</listitem> =

+				</itemizedlist>
+			</para>
+		</formalpara>
+		<formalpara>
+			<title>Core Server</title>
+			<para>
+				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1636">JBPAPP=
-1636</ulink>: When an adapter handled the scheduling of work to be perform=
ed, the <classname>ExecutionContext</classname> class contains a value in s=
econds, from which the <methodname>getCompletionTimeout</methodname> method=
 of <classname>org.jboss.resource.work.WorkWrapper</classname> obtains its =
information. An issue arises with <methodname>getCompletionTimeout</methodn=
ame> expecting the value to be in milliseconds, creating an error where the=
 initially set timeout value may be 6 seconds but be passed to the thread p=
ool as 6 milliseconds. The <filename>WorkWrapper.java</filename> file has b=
een updated and correctly converts the timeout value from seconds to millis=
econds.
+						</para>
+						<important>
+							<para>
+								This bug only affected third party adapters running within the JBo=
ss Application Server. =

+							</para>
+						</important>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1635">JBPAPP=
-1635</ulink>: The <classname>OracleExceptionSorter</classname> has been en=
hanced for this release with new error codes of 17002 (connection reset) an=
d 17008 (connection closed) now able to be handled. These enhancements have=
 been applied to the <filename>OracleExceptionSorter.java</filename> file.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1602">JBPAPP=
-1602</ulink>: A <exceptionname>ConcurrentModificationException </exception=
name> would occur when a classloader would be undeployed while another user=
 was attempting to load a class from the package. This error arose because =
the <classname>packagesMap</classname> within <classname>UnifiedLoaderRepos=
itory3</classname> had a <classname>TreeSet</classname> that was not correc=
tly synchronized with changes. In order to rectify this, the <filename>Clas=
sLoaderUtils.java</filename> file has been updated to import the <classname=
>Collections</classname> library and use the <methodname>synchronizedSet</m=
ethodname> method of the library in returning the <methodname>TreeSet</meth=
odname> of the <methodname>newPackageSet</methodname> method.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1540">JBPAPP=
-1540</ulink>: Within the cluster section of the EAP, the <classname>Gossip=
Router</classname> and <classname>GossipClient</classname> (TCPGOSSIP) did =
not have socket read timeouts, socket linger timeouts and backlog set to pr=
ovide 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. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1539">JBPAPP=
-1539</ulink>: When running parallel instances of the EAP on Linux a bug ex=
isted where messages between the JGroups component of each instance would b=
e picked up by both because all messages sent to the port number for Multic=
ast Sockets would be picked up by both instances. The issue has been fixed =
by re-writing the code for Multicast Sockets so that the constructor uses a=
 group address along with the port number as identifiers. This ensures that=
 an instance of the EAP only receives messages pertaining to its specific g=
roup and thus inhibits channel crosstalk.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1538">JBPAPP=
-1538</ulink>:The Probe Client had not been updated to use the same address=
 as the Probe Listener does which is now 224.0.75.75. Correcting this issue=
, the Proble Client now uses 224.0.75.75 instead of 224.0.0.75 which allows=
 the client and the listener to work together correctly. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1535">JBPAPP=
-1535</ulink>: The JDBCExtCacheLoader didn't handle persistent state transf=
ter correctly since the <methodname>storeState</methodname> method would us=
e avaliable space on the <classname>MarshalledValueInputStream</classname> =
instead of on the <classname>ByteArrayInputStream</classname>. To correct t=
he stream usage, <filename>JDBCExtendedCacheLoader.java</filename> has been=
 updated to store the new state using the <varname>in_stream</varname> valu=
e as long as there is space avaliable.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1534">JBPAPP=
-1534</ulink>: The JDBCCacheLoader didn't work with Sybase as it tried to s=
et a null <varname>BLOB</varname> (Binary Large OBject) column which is uns=
upported in Sybase. To correct this the <filename>JDBCCacheLoader.java</fil=
ename> and <filename>AdjListJDBCCacheLoader.java</filename> files have been=
 updated to select the Sybase Driver if Sybase is to be used, ensuring that=
 null values are set as <varname>LONGVARBINARY</varname> rather than <varna=
me>BLOB</varname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1532">JBPAPP=
-1532</ulink>: The JGroups clustering component of the EAP has been upgrade=
d to version 2.4.5. A list of the included fixes is as follows:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									The probe listener within JGroups still used the old default addr=
ess of 224.0.0.75 instead of the new address of 224.0.75.75. The probe list=
ener within JGroups has been updated with this release to use the correct d=
efault address.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The MPING protocol which sends a multicast ping over TCP containe=
d cross-talk in Linux. the MPING protocol has since been corrected to elimi=
nate cross-talk on the Linux platform.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									A problem was encountered within JGroups when two distinct proces=
ses were setup on the same machine, each using a different stack with diffe=
rent UDP multicast addresses. The issue was that each process would not wor=
k correctly because of the other, as each process would receive incorrect d=
atagrams in reference to the groups each joined. To correct this the <class=
name>MulticastSocket</classname> constructor is now used in combination wit=
h a <varname>SocketAddress</varname> when JGroups is used on the Linux plat=
form.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <literal>Gossip Router</literal> component of JGroups provide=
d options to set <literal>backlog</literal>, <literal>socket read timeout</=
literal> and <literal>socket linger timeout</literal> within the code, howe=
ver these options are not avaliable via the command line. This update of th=
e JGroups component, now includes the availability of these options to be s=
et through the command line. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									Within the <literal>Gossip Router</literal> component of JGroups =
<methodname>Math.min</methodname> was used in calculating the socket linger=
 timeout which caused incorrect results since this meant that the socket li=
nger timeout would always be 1. <literal>Gossip Router</literal> has been u=
pdated to instead use <methodname>Math.max</methodname> in the calculation =
of the socket linger timeout.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>RouterStub</classname> and <classname>GossipRouter=
</classname> classes have the <varname>setSoLinger</varname> value set inco=
rrectly to use a seconds value when <varname>setSoLinger</varname> uses mil=
lisecond values. This meant that a value of 500 was 500 seconds rather than=
 500 milliseconds. The <classname>RouterStub</classname> class has had its =
<varname>setSoLinger</varname> corrected and the <classname>GossipRouter</c=
lassname> class has had the <varname>setSoLinger</varname> value corrected =
and timouts configurable.
+								</para>
+							</listitem>
+						</itemizedlist>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1530">JBPAPP=
-1530</ulink>: The JCA adapter inflow did not roll back messages if a non-x=
a connection factory was being used within the JNDIProviderAdapter. In orde=
r to fix this issue the <filename>JmsServerSession.java</filename> file has=
 been updated with added logic to the local transaction  seperation strateg=
y as to allow for non-xa sessions to be rolled back using transaction sessi=
on.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1521">JBPAPP=
-1521</ulink>: The <classname>CleanShutdownInterceptor</classname> class wo=
uld log a <exceptionname>GenericClusteringException</exceptionname> when th=
e container had failed to shut down correctly or failed to start correctly =
and because of this behavior the error message displayed because of the exc=
eption should be updated to indicate that it may be an issue with the conta=
iner failing to start instead of only failing to shut down. In this latest =
EAP update, the error message has been updated to reflect both situations w=
hich may be the cause of the exception.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1458">JBPAPP=
-1458</ulink>: The JTA recovery configuration did not contain a line to ena=
ble JBoss Messaging (JBM) <classname>XAResourceRecovery</classname> even th=
ough it is stated in the JBM user guide. This CP release modifies the <file=
name>build-distr.xml</filename> file to all <classname>XAResourceRecovery</=
classname> to be enabled for JTA recovery.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1479">JBPAPP=
-1479</ulink>: Within the different distributions of the EAP that are 4.2 a=
nd 4.3, both the <filename>JBossMQ</filename> and <filename>JBoss Messaging=
</filename> application policies have been present within the <filename>log=
in-config.xml</filename> file, when <filename>JBossMQ</filename> is only in=
cluded 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>buil=
d.xml</filename> and <filename>login-config.xml</filename> to differentiate=
 between requirements for each individial distribution. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1473">JBPAPP=
-1473</ulink>: The <classname>IgnoreUndeployLegacyClusteredSessionNotificat=
ionPolicy</classname> within clustering didn't correctly call <classname>is=
HttpSessionListenerInvocationAllowed</classname>, which would lead to the r=
epeated calling of itself and eventually <exceptionname>StackOverflow</exce=
ptionname> errors. In order to correct this the <filename>IgnoreUndeployLeg=
acyClusteredSessionNotificationPolicy.java</filename> file has been modifie=
d to correctly call <classname>isHttpSessionListenerInvocationAllowed</clas=
sname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1460">JBPAPP=
-1460</ulink>: The JavaServer Faces (JSF) has been updated to version 1.2_1=
0 for this EAP release. This update corrects numerious bugs and details on =
these fixes can be found at <ulink url=3D"https://javaserverfaces.dev.java.=
net/nonav/rlnotes/1.2_10/changelog.html">https://javaserverfaces.dev.java.n=
et/nonav/rlnotes/1.2_10/changelog.html</ulink>
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"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 b=
een updated with a calling to an new <methodname>SQLUtil.fixConstraintName<=
/methodname> function which changes all dots in a constraint name to unders=
cores. This ensures that constraint names are compatable with Oracle.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1307">JBPAPP=
-1307</ulink>: The Persistence Unit (PU) root was incorrectly detected with=
in deployments that contained nested <filename>.jar</filename> files. The r=
oot PU was being detected as the first nested <filename>.jar</filename> enc=
ountered instead of being the deployment which contains the <filename>persi=
stence.xml</filename> file. To make sure that the PU root is always set cor=
rectly, the <filename>JmxDeploymentUnit.java</filename> file has been updat=
ed with the removal of testing for the url being null and the <parameter>de=
ploymentInfo.parent</parameter> not being null. This means that the url is =
now always taken straight from the <parameter>extractDescriptorUrl</paramet=
er> of <filename>META-INF/persistence.xml</filename>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1289">JBPAPP=
-1289</ulink>: The JBoss JAXR component of the EAP has been upgraded to ver=
sion 1.2.0.SP2. A list of the included fixes is as follows:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									In the <filename>org.jboss.jaxr.juddi.JUDDIServlet</filename> and=
 <filename>org.jboss.jaxr.juddi.transport.SaajTransport</filename> files th=
e namespace value for <varname>xml:lang</varname> contained <literal>http:/=
/www.w3.org/TR/REC-xml/</literal>, which caused an exception within the met=
ro stack. The namespace value should instead be null and this has been appl=
ied for this JAXR update.
+								</para>
+							</listitem>
+						</itemizedlist>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"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 applica=
tion which heavily used Xalan within large multi-threaded environments woul=
d encounter blocking situatinos.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"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 corre=
ctly. This has been fixed by modifying numerious files which make <classnam=
e>UserTransaction</classname> deployable with transaction sticky load balan=
ce policies. =

+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1249">JBPAPP=
-1249</ulink>: The JSF component of the EAP has been upgraded to version 1.=
2_10. A list of the included fixes is as follows:
+						</para>
+						<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> fil=
e was updarted with the removal of <code>ELUtils.getScope(this.expressionSt=
ring, segment);</code> in order to fix this issue.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<methodname>LifecycleImpl</methodname> and <methodname>RestoreVie=
wPhase</methodname> forced the <methodname>responseComplete()</methodname> =
method for the status of an existing view. To correct this problem the <fil=
ename>RestoreViewPhase.java</filename> file has been edited with the code <=
code>facesContext.responseComplete();</code> removed and replaced with <cod=
e>facesContext.renderResponse();</code>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									For a &lt;h:dataTable&gt; tag which does not set the <varname>var=
</varname> attribute, if the UIData component is created using a binding an=
d calls the <methodname>setVar()</methodname> method to set the <varname>va=
r</varname> attribute, it would be overwritten as a null value by the &lt;h=
:dataTable&gt; tag. This bug has been fixed by modifying the <filename>Html=
Taglib21Generator.java</filename> file so that component properties are not=
 set if the tag attribute has not been set.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>BindingValidator</classname> would generate a <exc=
eptionname>ConverterException</exceptionname> instead of a <exceptionname>V=
alidatorException</exceptionname>. For this update, <classname>BindingValid=
ator</classname> has been modified to generate the correct exception; <exce=
ptionname>ValidatorException</exceptionname>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The cause of a <classname>PostConstruct</classname> exception wit=
hin the <classname>BeanBuilder</classname> was not communicated to the user=
 correctly. To correct the issue so that no information is hidden from the =
user, the <exceptionname>ManagedBeanCreationException</exceptionname> has b=
een updated to provide more information about the cause of the exception.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									An issue was present that would cause majarra to execute <filenam=
e>faces-config.xml </filename> initialization files twice, creating duplica=
te operations. This was caused since a record was not kept of which files h=
ad been intialized and which had not. File initialization tracking has been=
 implemented to correct this issue and this has seen the modification of th=
e following files: <filename>ConfigManager.java</filename>, <filename>Confi=
gureListener.java</filename>, <filename>WebConfiguration.java</filename>, <=
filename>ConfigurationResourceProvider.java</filename>, <filename>MetaInfRe=
sourceProvider.java</filename>, <filename>RIConfigResourceProvider.java</fi=
lename> and <filename>WebResourceProvider.java</filename>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>com.sun.faces.renderkit.ApplicationObjectInputStre=
am</classname> extends the functionality of <classname>java.io.ObjectInputS=
tream</classname> but failed to preserve the functionality as <classname>co=
m.sun.faces.renderkit.ApplicationObjectInputStream</classname> would fail w=
hen primitives were used, unlike the <classname>java.io.ObjectInputStream</=
classname> class which contains a special case to handle such a case. This =
would cause problems for <literal>UIComponents</literal>. <filename>Applica=
tionObjectInputStream.java</filename> has been updated to explicitly handle=
 primitive cases and catch the <exceptionname>ClassNotFoundException</excep=
tionname> which may be generated.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<classname>com.sun.faces.renderkit.html_basic.OutputLinkRenderer<=
/classname> did not encode parameters correctly, missing the <literal>URLEn=
coding</literal>. <literal>URLEncoding</literal> has been added, correcting=
 this bug, along with the parameter names. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>com.sun.faces.renderkit.html_basic.BaseTableRender=
er</classname> did not allow for empty <varname>columnClasses</varname> whe=
n generating columns from user unput. The issue was realizing when to creat=
e numerious columns rather just one; for instance if the user input <litera=
l>foo, </literal> with a trailing space then the expected output would be o=
ne column with the name <literal>foo</literal> and another empty column. Th=
is was not the case though, as <literal>foo, </literal> would generate just=
 one column with <literal>foo, </literal> in its entirety as the column nam=
e, instead of spliting the columns on the comma. This behaviour has now bee=
n corrected so that <classname>com.sun.faces.renderkit.html_basic.BaseTable=
Renderer</classname> no generates columns correctly, and in order to achiev=
e this the following files have been updated: <filename>BasetableRenderer.j=
ava</filename>, <filename>GridRenderer.java</filename> and <filename>TableR=
enderer.java</!
 filename>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>com.sun.faces.renderkit.html_basic.MenuRenderer</c=
lassname> class did not correctly differentiate between <literal>Objects</l=
iteral>; for instance the different between <literal>Boolean</literal> and =
<literal>boolean</literal>, noting the capitalization of the first. The err=
or was with the logic in <classname>UISelect</classname> and <classname>Men=
uRenderer</classname>. To correct this, proper use of the converter for the=
se classes has been implemented to deal with Objects correctly.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<classname>com.sun.faces.lifecycle.RestoreViewPhase</classname> c=
alled <methodname>DebugUtil.printTree</methodname> after restoring the view=
 if debugging was enabled, causing incorrect initialization of calls when a=
 listbox is being used and returning an incorrect value in the <classname>R=
enderResponse</classname> phase. Method calls have been restructured with t=
he removal of references to the <methodname>DebugUtil.printTree()</methodna=
me> method from <filename>ViewHandlerImpl.java</filename> and <filename>Res=
toreViewPhase.java</filename> and <filename>RenderResponsePhase.java</filen=
ame> has been modified to call <methodname>DebugUtil.printTree</methodname>=
 (if <varname>FINEST</varname> logging is enabled) at the end of the <class=
name>RenderResponse</classname> phase, fixing the issue (with the above cha=
nges also) and providing a more accurate view of the tree. 												</pa=
ra>
+							</listitem>
+							<listitem>
+								<para>
+									<literal>CGLIB Enhanced UIComponents</literal> in a component tre=
e would return a value of null for their class when calling <methodname>get=
Package()</methodname> causing <classname>HtmlInputText.handleAttribute</cl=
assname> to fail as it relies on a not-nulll value. This issue has been cor=
rected by ignoring a returned value of null from the <methodname>getPackage=
()</methodname> method for every instance in the codebase.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>UIComponentBase</classname> did not allow for the =
children of a tree to be iterated through in reverse order using a list ite=
rator as it would produce an <exceptionname>IndexOutOfBoundsException</exce=
ptionname> when the execution tries to calculate the size of the children. =
<methodname>ChildrenListIterator</methodname> method has been modified with=
in the <classname>UIComponentBase</classname> class by changing the line of=
 code <code>if ((index &lt; 0) || (index &gt;=3D list.size())) { </code> to=
 <code>if ((index &lt; 0) || (index &gt; list.size())) {</code>. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									Renderer kits for <filename>faces-config.xml</filename> were proc=
essed 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 rende=
rer DOM nods in a list associated with a namespace. This was done so that t=
he renderer nodes could then be processed prior to the <literal>RenderKits<=
/literal> being created and the nodes could be processed using the proper n=
amespace. However, by placing all the renderers into this list, we lost the=
 document ordering. The issue has been fixed by associating the renderer no=
des with their owning document and processed in the parsing order. =

+
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <methodname>Class.getPackage()</methodname> method calls to s=
ynchronized methods, inhibiting scalability if the method has to be repeate=
dly executed. Use of the <methodname>Class.getPackage()</methodname> method=
 has now been removed from <filename>UIComponent.java</filename>, <filename=
>RenderKitUtils.java</filename> and <filename>HtmlComponentGenerator.java</=
filename>. Instead, the class name is now checked if it starts with the pac=
kage name that is of interest, <classname>javax.faces.component.</classname=
>. This includes the components that are generated by the <classname>HtmlCo=
mponentGenerator</classname> since they are packaged in <classname>javax.fa=
ces.component.html</classname>. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									A bug presented itself in the <classname>RenderKitUtils</classnam=
e> class when a semicolon (<code>;</code>) followed a forward-slash (<code>=
/</code>) in a header Accept value (for instance: <code>text/;q=3D0.5</code=
>). To rectify this issue the <classname>RenderKitUtils</classname> class h=
as been updated to assume <code>*</code> as the subtype for an Accept heade=
r that contains no subtype. =

+								</para>
+							</listitem>
+						</itemizedlist>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1224">JBPAPP=
-1224</ulink>: Attribute default values in EJB were not set when in use wit=
h <literal>@Service</literal> and <literal>XMBean XML</literal> . In order =
to correct this the behavior has been re-written to improve the mimicking o=
f <classname>ServerCreator</classname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1170">JBPAPP=
-1170</ulink>: When the <methodname>getMBeanInfo</methodname> method is cal=
led within <classname>MBeanServerImpl</classname> and <classname>RawDynamic=
Invoker</classname>, the underlying exception to <exceptionname>NotComplian=
tMBeanException</exceptionname> is not expressed to the user. <filename>Raw=
DynamicInvoker.java</filename> has now been updated to provide this useful =
information to the user.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1099">JBPAPP=
-1099</ulink>: The <filename>commons-beanutils.jar</filename> file within t=
he EAP had the incorrect version in the <filename>manifest.mf</filename> fi=
le. Through the course of correcting this bug, it was found that the <liter=
al>beanutils</literal> component was outdated and a newer version contained=
 manu advantages. In this update to the EAP <literal>beanutils</literal> ha=
s been upgraded to version 1.8.0, which sees the significant improvement th=
at fixes a memory leak caused by a circular reference concerning the <class=
name>WeakHashMap</classname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"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. Howe=
ver this was an error as BMT Stateful Session Beans are allowed to have thi=
s occurance and so this logging measure has been removed in this EAP update.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-996">JBPAPP-=
996</ulink>: Discrepancies existed between the port schemes within the <fil=
ename>sample-bindings.xml</filename> file. These include:
+						</para>
+						<itemizedlist>
+							<listitem>
+								<para>
+									The remoting connectors were inserted in different places within =
the ports definition sections, making the comparison of the sections more d=
ifficult than was necessary. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <literal>ports-03</literal> section was missing the <literal>=
EJB remoting connector</literal> and the <literal>remoting connector</liter=
al> sections. =

+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<literal>mq</literal> was used in the name property of the <varna=
me>HAJNDIJMSProvider</varname> instead of <literal>jms</literal>.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <literal>ports-01</literal>, <literal>ports-02</literal>, and=
 <literal>ports-03</literal> schemes defined the <varname>timeout</varname>=
 attribute twice in the <literal>JBoss Messaging</literal> section:
+
+								</para>
+							</listitem>
+						</itemizedlist>
+						<para>
+							The above issues have been fixed appropriately in this update.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-713">JBPAPP-=
713</ulink>: A Classloader leak existed causing a <errorname>OutOfMemoryErr=
or: PermGen</errorname> error. To correct this issue the EAP now uses <file=
name>beanutils 1.8.0</filename> which fixes this <errorname>OutOfMemoryErro=
r</errorname>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-529">JBPAPP-=
529</ulink>: JMX source code was being exposed to the user when a <exceptio=
nname>HTTP Status 500</exceptionname> exception would occur. To correct thi=
s, an error page <filename>genericError.jsp</filename> has been created and=
 is now displayed whenever a <exceptionname>HTTP Status 500</exceptionname>=
 exception occurs.
+						</para>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</formalpara>
+	</section>
+	<section id=3D"Known_Issues_with_this_release">
+		<title>
+			Known Issues with this release
+		</title>
+		<para> =

+			Following is a list of known issues at the time of release.
+		</para>
+		<itemizedlist>
+			<listitem>
+				<para>
+					<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-1286">JBPAPP-1=
286</ulink>: Footnotes within documentation tables and lists do not appear =
within PDFs. This issue resides within FOP and currently no workaround exis=
ts. Where possible footnotes are not used in the circumstances mentioned, h=
owever 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.  =

+				</para>
+			</listitem>
+			<listitem>
+				<para>
+					<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-909">JBPAPP-90=
9</ulink>: Within the Hibernate component of the EAP the HashMap and HashSe=
t iteration order changed from past releases because of support for JDK 1.6=
. However this has meant that the order of columns in union clauses and uni=
on-subclasses has changed, generating a slight impact on the components per=
formance. =

+				</para>
+			</listitem>
+			<listitem>
+				<para>
+					<ulink url=3D"http://jira.jboss.com/jira/browse/JBPAPP-885">JBPAPP-88=
5</ulink>: An issue exists where if <methodname>DefaultRedeliveryDelay</met=
hodname> or <methodname>RedeliveryDelay</methodname> is set to a value apar=
t from zero, messages will not be redelivered even though the method <metho=
dname>session.rollback()</methodname> had been called. This issue will not =
be fixed because redelivery delay is handled on the server side and the mes=
sage is already acknowledged before delivery of the message with a non dura=
ble subscription. For the Enterprise Application Platform, this means that =
redelivery delays with non durable subscriptions cannot be supported.
+				</para>
+			</listitem>
+		</itemizedlist>
+	</section>
+-->
+<xi:include xmlns:xi=3D"http://www.w3.org/2001/XInclude" href=3D"Revision_=
History.xml"/>
+
+</article>


--===============0240041369417024182==--