[jboss-cvs] JBossAS SVN: r89417 - projects/docs/enterprise/4.3.5/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon May 25 23:22:57 EDT 2009
Author: irooskov at redhat.com
Date: 2009-05-25 23:22:57 -0400 (Mon, 25 May 2009)
New Revision: 89417
Modified:
projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
Log:
updated release notes with new JIRA
Modified: projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
===================================================================
--- projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-05-26 00:03:04 UTC (rev 89416)
+++ projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-05-26 03:22:57 UTC (rev 89417)
@@ -49,12 +49,12 @@
This section details the versions of the components which create the Enterprise Application Platform 4.3 that can be found in this Cumulative Patch release.
</para>
<itemizedlist>
- <!-- <listitem>
+ <listitem>
<para>
JBoss Application Server 4.2.z
</para>
</listitem>
- <listitem>
+ <!-- <listitem>
<para>
Hibernate Core 3.2.4.SP1.CP07
</para>
@@ -83,13 +83,13 @@
<para>
JBoss JAXR 1.2.0.SP2
</para>
- </listitem>
+ </listitem> -->
<listitem>
<para>
- JBoss Messaging 1.4.0.SP3-CP06
+ JBoss Messaging 1.4.0.SP3-CP08
</para>
</listitem>
- <listitem>
+ <!-- <listitem>
<para>
JBoss Remoting 2.2.2.SP11
</para>
@@ -363,18 +363,87 @@
<para>
Following is a list of issues fixed in this release:
</para>
- <!-- <formalpara>
+ <formalpara>
<title>JBoss Messaging</title>
<para>
<itemizedlist>
<listitem>
<para>
-
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2029">JBPAPP-2029</ulink>: The JBoss Messaging component of the Enterprise Application Platform has been upgraded to version 1.4.0.SP3-CP08. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1620">JBMESSAGING-1620</ulink>: JBoss Messaging did not display any notifications when the client connections were closed and this feature was now being requested. In order to include this feature, the <filename>SimpleConnectionManager.java</filename> file has been updated to synchronize the <classname>AspectManager</classname> instances and create a new connection advisory before the connection close in order to capture the notifications when the close occurs.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1614">JBMESSAGING-1614</ulink>: The limit for bridges was formally 256 as each bridge participant required a unique ServerPeerID that was an 8-bit value. However users have wished to bridge more than 256 servers to a single host and to allow for this the limit has been increased to 65535 (16-bit).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1608">JBMESSAGING-1608</ulink>: A bug arose when the server instance of JBoss Messaging performed a restart as the <classname>MessagingXAResourceRecovery</classname> instance on the client machine would not reconnect correctly to the new server instance and instead display a warning to the user concerning a generated exception in the program. This issue has been corrected by modifying the <filename>MessagingXAResourceWrapper.java</filename> file to verify the connection, catch any generated <exceptionname>JMSException</exceptionname> and test if the connection is still valid following an exception.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1607">JBMESSAGING-1607</ulink>: When the <filename>bisocket-remoting-service.xml</filename> was updated in pervious releases, the <filename>sslbisocket-remoting-service.xml</filename> missed being updated accordingly. The following patameters were missing and have now been added in order to ensure remoting configuration functions correctly:
+ </para>
+<programlisting>
+<attribute name="validatorPingPeriod" isParam="true">10000</attribute>
+<attribute name="validatorPingTimeout" isParam="true">5000</attribute>
+<attribute name="registerCallbackListener">false</attribute>
+</programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1591">JBMESSAGING-1591</ulink>: When a system crash would occur, the server would not properly close references to instances of the <classname>ServerInvokerCallbackHandler</classname>, resulting in a memory leak. This bug has been corrected by modifying the <filename>ServerConnectionEndpoint.java</filename> file so that the <methodname>callbackHandler.shutdown();</methodname> method is called in the <code>try</code> code instead of calling <methodname>callbackHandler.getCallbackClient().disconnect();</methodname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1562">JBMESSAGING-1562</ulink>: Channel name resolution was not correct in the <methodname>MessagingPostOfficeService.startService()</methodname> method. Where the code was:
+ </para>
+<programlisting>
+String channelName = (channelPartitionName == null)? channelPartitionName : groupName;
+</programlisting>
+ <para>
+ The code now is:
+ </para>
+<programlisting>
+String channelName = (channelPartitionName != null)? channelPartitionName : groupName;
+</programlisting>
+ <para>
+ Where the difference is that the <varname>channelPartitionName</varname> is tested to not be null instead of being null. This ulteration ensures that the channel name is resolved correctly.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1547">JBMESSAGING-1547</ulink>: A potential deadlock case may have eventuated in earlier releases of JBoss Messaging when a message <methodname>Sucker</methodname> was being stopped due to the remote queue leaving, while the corresponding <methodname>localQueue</methodname> was delivering messages and trying to pass messages to its <methodname>Suckers</methodname>. In order to ensure this deadlock can no longer occur, the <filename>MessageSucker.java</filename> file has been updated to move the <methodname>localQueue.unregisterSucker(this)</methodname> method call to the beginning of the <methodname>stop()</methodname> method in order to prevent the message <methodname>Sucker</methodname> from being accessed while it is shutting itself down.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1543">JBMESSAGING-1543</ulink>: If a <emphasis>Message Bridge</emphasis> failed on the first attempt at connecting to a server because of any reason and then the server was found, the bridge connection would still fail (unless explicitly instructed to reconnect) even though a success message is displayed to the user. The issue is fixed by editing <filename>Bridge.java</filename> to ensure that the <classname>StartupFailureHandler</classname> starts the checker thread even if the bridge connection fails so that it is ready to start on a successful reconnection.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1516">JBMESSAGING-1516</ulink>: Functionality has been added to the <classname>MessagingPostOffice</classname> where users can now perform changes to the <property>failoverOnNodeLeave</property> property in order to give administrators improved flexibility with whould should occur when a JBoss Messaging cluster node is shutdown under normal circumstances.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1456">JBMESSAGING-1456</ulink>: Messages would not move from the <property>being-delivered</property> state when clients used a clustered XA connection factory in a cluster of at least two nodes.
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
- </formalpara> -->
+ </formalpara>
<formalpara>
<title>JBoss Cache</title>
<para>
More information about the jboss-cvs-commits
mailing list