[jboss-cvs] JBossAS SVN: r82850 - projects/docs/enterprise/4.3.4/readme/en-US.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Wed Jan 14 01:22:05 EST 2009 

Author: irooskov at redhat.com
Date: 2009-01-14 01:22:05 -0500 (Wed, 14 Jan 2009)
New Revision: 82850

Modified:
   projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
Log:
updated release notes with remoting JIRAs


Modified: projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
===================================================================
--- projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml	2009-01-14 06:12:01 UTC (rev 82849)
+++ projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml	2009-01-14 06:22:05 UTC (rev 82850)
@@ -301,8 +301,75 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="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.
+							<ulink url="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>ConnectionValidator.start()</methodname> was called, resulting in the <varname>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 are now checked to see if they are null upon execution of the <methodname>ConnectionValidator.run()</methodname> method, one or both are then an <exceptionname>IllegalStateException</exceptionname> is displayed to the user outlining that <methodname>ConnectionValidator.run()</methodname> should not be called directly but <methodname>addConnectionListener()</methodname> should be used instead.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									Two bugs existed within the <methodname>org.jboss.remoting.marshal.MarshallerLoaderHandler.loadClassBytes()</methodname> method that prohibited 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 call to the <methodname>org.jboss.mx.loading.LoaderRepository.getCachedClass()</methodname> method should have been a general call to <methodname>LoaderRepository.loadClass()</methodname>. These two issues have been rectified with this Remoting update, allowing remote classloading to function correctly.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									A bug existed within the Remoting component by which the RemotingClassLoader would always attempt to load a class over the network first if remote classloading was enabled, leading to conflicts if the class was avaliable locally before. The code has been corrected to check locally first before looking remotely. 
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>ServerInvokerCallbackHandler</classname> class would become unresponsive when calling the <methodname>BlockingCallbackStore.add()</methodname> method after locking the callback field with a true responce 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 period, however this could not be achieved because of the wait period. To fix this issue the call to the <methodname>BlockingCallbackStore.add()</methodname> method has been removed as it was an unnecessary step. 
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									The <classname>HTTPClientInvoker</classname> did not support Beginner's All-purpose Symbolic Instruction Code (BASIC) authentication for proxies when the proxy was configured through system property options of <methodname>http.proxyHost</methodname> and <methodname>http.proxyPort</methodname>. The issue appears because the <classname>HTTPClientInvoker</classname> would not check for the existence of these options and in tern it would never create a <methodname>Proxy-Authorization</methodname> request header, which is necessary for normal opperation. To fix this the <classname>HTTPClientInvoker</classname> has been modified to check for the existence of the <methodname>http.proxyHost</methodname> option and if it detects its use, creates a <methodname>Proxy-Authorization</methodname> request header.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<classname>HTTPClientInvoker</classname> would generate a <exceptionname>NullPointerException</exceptionname> when the HTTP server returned an error code without any content and then the <methodname>java.net.HttpUrlConnection.getInputStream()</methodname> method returned a null value. In order to improve control over this behavior, the new variable <varname>UNMARSHAL_NULL_STREAM</varname> has been added to the <classname>HTTPClientInvoker</classname>. If this variable is set to true (the default value) the default behavior is executed, however if it is set to false the call to the <methodname>UnMarshaller.read()</methodname> is skipped.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									Within the <classname>InvokerRegistry</classname> an error existed associated with the sequencing of events and <classname>serverLocators</classname>  would return a null on occasion. To correct this race condition, the sequencing of events within the <classname>InvokerRegistry</classname> has been rearragned so that references to <classname>transportClientFactoryClasses</classname> and <classname>clientLocators</classname> are governed by <classname>clientLock</classname> and references to <classname>transportServerFactoryClasses</classname>, <classname>serverLocators</classname>, and <classname>registeredLocators</classname> are governed by <classname>serverLock</classname>.
+								</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 overloaded <methodname>org.jboss.remoting.Client</methodname> method was called and the <varname>DEFAULT_PING_PERIOD</varname> variable value was placed into the metadata map passed to the <classname>ConnectionValidator</classname>. This has been corrected by updating <classname>org.jboss.remoting.Client.addConnectionListener</classname> so that <varname>DEFAULT_PING_PERIOD</varname> is only passed if the value of <varname>VALIDATOR_PING_PERIOD</varname> within the client's configuration map has not been set. 
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<classname>ConnectionValidator</classname> may become unresponsive then the <methodname>run()</methodname> method is executed and utilizes the <varname>lock</varname> variable. The methods within the <methodname>run()</methodname> method are meant to time out so that the <varname>lock</varname> variable can become avaliable to the <methodname>notifyListeners()</methodname> in the event of a network failure; however <methodname>run()</methodname> may execute again before <methodname>notifyListeners()</methodname> can. The synchronization on the <varname>lock</varname> variable has been modified to avoid this issue to enable correct operation.
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									
+								</para>
+							</listitem>
+						</itemizedlist>
 					</listitem>
 				</itemizedlist> 
 			</para>
@@ -488,7 +555,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-">JBPAPP-</ulink>:
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1548">JBPAPP-1548</ulink>: An exploit existed within the JBoss Web Services component of the EAP that would allow anyone to view any xml file from any location if <literal>&amp;resource=path/of/an/xmlfile.xml</literal> was applied to the end of any WSDL (Web Services Definition Language) access URL. The <filename>WSDLRequestHandler.java</filename> file has been updated to only allow the parent of a WSDL file, a servers data or WSDL or overriden WSDL publish directories access to xml file resources. Additional test files are also included which were created to ensure proper opperation was being undertaken.
 						</para>
 					</listitem>
 				</itemizedlist>

More information about the jboss-cvs-commits mailing list