[jboss-cvs] JBossAS SVN: r89580 - projects/docs/enterprise/4.3.5/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sun May 31 23:03:06 EDT 2009
Author: irooskov at redhat.com
Date: 2009-05-31 23:03:06 -0400 (Sun, 31 May 2009)
New Revision: 89580
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-30 22:54:03 UTC (rev 89579)
+++ projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-06-01 03:03:06 UTC (rev 89580)
@@ -489,6 +489,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1128">JBREM-1128</ulink>:
+ </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>
@@ -525,6 +530,16 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1102">JBREM-1102</ulink>: A feature was requested that would make the configuration map avaliable to the <classname>marshalFactory</classname>. In order to support this the new parameter <property>org.jboss.remoting.Remoting.PASS_CONFIG_MAP_TO_MARSHAL_FACTORY</property> has been added, which requires a setting of <emphasis>true</emphasis> in order to have the configuration map passed to the <classname>marshalFactory</classname>. If the parameter contains a value of <emphasis>false</emphasis> then the original behavior will be executed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1100">JBREM-1100</ulink>: A feature was requested whereby <classname>ServerInvokerServlet</classname> instances could be linked to <classname>Connectors</classname> by MBean names rather than locator URLs. In order to achieve this the parameter <property>org.jboss.remoting.transport.servlet.ServletServerInvoker.CREATE_UNIQUE_OBJECT_NAME</property> has been added. When set to <emphasis>true</emphasis>, <methodname>ServletServerInvoker.getMBeanObjectName()</methodname> will call <methodname>org.jboss.remoting.ServerInvoker.getMBeanObjectName()</methodname> and return an <emphasis>ObjectName</emphasis> derived by the same algorithm that is used for all transports. To ensure the original default behavior remains, the default value is <emphasis>false</emphasis>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBREM-1099">JBREM-1099</ulink>: The multicast detector did not work correctly in environments where many JBoss Remoting invokers were being used. The <methodname>org.jboss.remoting.detection.AbstractDetector.createDetection()</methodname> method would create a detection message based on the number of server inokers registered locally. In the JBoss Enterprise Application Server this would cause an error as the message size would exceed the 4000 limit. A <property>buffersize</property> attribute has been created for <classname>org.jboss.remoting.detection.multicast.MulticastDetector</classname> and <classname>org.jboss.remoting.detection.multicast.MulticastDetectorMBean</classname> that defaults to a value of 10000.
</para>
</listitem>
@@ -535,11 +550,16 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBREM-1081">JBREM-1082</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1084">JBREM-1084</ulink>: When <methodname>org.jboss.remoting.Client.addConnectionListener()</methodname> created a <classname>CallbackPoller</classname>, a reference to itself and a metadata map would be passed. The issue arose from the <classname>CallbackPoller</classname> only accessing parameters in the metadata map. To rectify this issue the <property>Client.USE_ALL_PARAMS</property> parameter is checked within the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map that is passed to the <methodname>Client.addListener()</methodname> method respectively. If the <property>useALLParams</property> property is found and set to a value of <emphasis>true</emphasis>, the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map will be searched respectively for all parameters used by <classname>CallbackPoller</classname>, otherwise only the metad!
ata map will be used, which is the default behavior.
</para>
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1082">JBREM-1082</ulink>: When <methodname>org.jboss.remoting.Client.addConnectionListener()</methodname> created a <classname>ConnectionValidator</classname>, a reference to itself would be passed and the <classname>ConnectionValidator</classname> would access the client's configuration map. The issue arose from the client's configuartion map not including the <classname>InvokerLocator</classname> parameters. To rectify this issue the <classname>ConnectionValidator</classname> now searches for the <property>Client.USE_ALL_PARAMS</property> parameter in the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map that is passed to the <methodname>Client.addConnectionListener()</methodname> method respectively. If the <property>useALLParams</property> property is found and set to a value of <emphasis>true</emphasis>, the <classname>ConnectionValidator</classname> will search for pa!
rameter values in the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map respectively.
+ </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