[jboss-cvs] JBossAS SVN: r89513 - projects/docs/enterprise/4.3.5/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri May 29 00:40:12 EDT 2009
Author: irooskov at redhat.com
Date: 2009-05-29 00:40:12 -0400 (Fri, 29 May 2009)
New Revision: 89513
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-29 04:40:01 UTC (rev 89512)
+++ projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-05-29 04:40:12 UTC (rev 89513)
@@ -484,11 +484,21 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBREM-1125">JBREM-1125</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1129">JBREM-1129</ulink>: It was possible for <emphasis>PING</emphasis> messages to arrive out of order because socket and bisocket transports use a pool of connections. To fix this bug when a <classname>org.jboss.remoting.Lease</classname> is created a timestamp is associated with it and carried by an initial <emphasis>PING</emphasis> message. The contents of an updated <emphasis>PING</emphasis> message will now be discarded if its timestamp is older than the previously processed timestamp. In the occurance that the initiating <emphasis>PING</emphasis> message does not have a time stamp, the lease will assume that the client is using an older version of JBoss Remoting and it will accept all updated <emphasis>PING</emphasis> messages.
</para>
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1127">JBREM-1127</ulink>: <exceptionname>ClassCastExceptions</exceptionname> would arise from the caching of <classname>Unmarsharller</classname> and <classname>Classloader</classname> in the <classname>MicroRemoteClientInvoker</classname> and performing classloading when accessing a remote bean from seperate isolated EARs. In fixing this issue the <filename>MicroRemoteClientInvoker.java</filename> file has been updated to modify the use of <methodname>useCurrentThreadClassLoader</methodname>, the variable <varname>useCurrentThreadClassLoader</varname> has been added to <filename>RemotingClassLoader.java</filename>, and <filename>JavaSerializationManager.java</filename> has been modified to update the <classname>ObjectInputStream</classname> classloader if the <varname>useCurrentThreadClassLoader</varname> variable of <classname>RemotingClassLoader</classname> has a value of true.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1125">JBREM-1125</ulink>: When a <classname>java.util.Timer</classname> class no longer had <classname>TimerTasks</classname> in its queue, it would allow itself to shut down. This behavior caused subsequent calls to the <methodname>Timer.schedule()</methodname> method to generate a <exceptionname>java.lang.IllegalStateException</exceptionname>. The exception has been overcome by modifying the <filename>AbstractDetector.java</filename> file to test for an <exceptionname>IllegalStateException</exceptionname> when scheduling on the <classname>heartbeatTimer</classname> and <classname>Timer</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBREM-1121">JBREM-1121</ulink>: Functionality has been added to the client <classname>SocketFactory</classname> that allows it to be configurable by the <classname>InvokerLocator</classname> so that all the parameters from the <classname>InvokerLocator</classname> are avaliable instead of only those in the configuration map.
</para>
</listitem>
@@ -525,6 +535,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1081">JBREM-1082</ulink>:
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBREM-1081">JBREM-1081</ulink>: When the method <methodname>ServerInvokerCallbackHandler.destroy()</methodname> shut down <classname>When org.jboss.remoting.callback.ServerInvokerCallback</classname>, the variables <varname>callBackClient</varname> and <varname>callbackStore</varname> were set to null. If the <methodname>ServerInvokerCallbackHandler.handleCallback()</methodname> is then called a <exceptionname>NullPointerException</exceptionname> arises because that variables <varname>callBackClient</varname> and <varname>callbackStore</varname> are set to null. This bug has been corrected in this latest release by the <methodname>ServerInvokerCallbackHandler.destroy()</methodname> method no longer assigning a value of null to the variables <varname>callBackClient</varname> and <varname>callbackStore</varname>.
</para>
</listitem>
More information about the jboss-cvs-commits
mailing list