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

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Tue Jun 2 19:31:53 EDT 2009


Author: irooskov at redhat.com
Date: 2009-06-02 19:31:53 -0400 (Tue, 02 Jun 2009)
New Revision: 89705

Modified:
   projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
Log:
updated with new JIRAs


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-06-02 22:21:24 UTC (rev 89704)
+++ projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml	2009-06-02 23:31:53 UTC (rev 89705)
@@ -99,11 +99,11 @@
 					JBoss Transactions 4.2.3.SP5.CP05
 				</para>
 			</listitem>
-		<!--	<listitem>
+			<listitem>
 				<para>
-					JBoss Web 2.0.0-6.CP09
+					JBoss Web 2.0.0.CP10
 				</para>
-			</listitem> -->
+			</listitem>
 			<listitem>
 				<para>
 					JBoss Web Services 2.0.1.SP2_CP06
@@ -436,11 +436,24 @@
 						</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.
+								<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 without a restart of the servers. This was caused because when the client connection failed, the server side would not always be notified, which meant that messages would not be canceled and redelivered. To correct this behavior a new feature was added to the JBoss Remoting component to inable the necessary strict binding between a client and the server connection failure management. Correct synchronization is achieved through this, also fixing an issue of inaccurate message counts. The following new parameters have been introduced to the Remoting configuration file:
 							</para>
+<programlisting>
+&lt;attribute name="failureDisconnectTimeout" isParam="true">0&lt;/attribute&gt;
+&lt;attribute name="callbackErrorsAllowed"&gt;1&lt;/attribute&gt;
+&lt;attribute name="useClientConnectionIdentity" isParam="true"&gt;true&lt;/attribute&gt; 
+</programlisting>
+							<para>
+								This fix means that a customer can be asured that JBoss Messaging reliably delivers messages without missing data or discontinuity of the mission critical application.
+							</para>
 						</listitem>
 						<listitem>
 							<para>
+								<ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1416">JBMESSAGING-1416</ulink>: The functionality of strict messaging has been added to the JBoss Messaging component. This allows for a user to determine an ordering group and only one message with the value of an ordering group is delieverd at once. After the message is acknowledged or cancelled the next message is delivered.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
 								<ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1131">JBMESSAGING-1131</ulink>: JBoss Messaging used to only use socket transport for delivering messages. In this latest release, JBoss Messaging now supports servlet transport through cooperation with the JBoss Remoting component, improving the functionality of JBoss Messaging.
 							</para>
 						</listitem>
@@ -555,7 +568,7 @@
 							</listitem>
 							<listitem>
 								<para>
-									<ulink url="http://jira.jboss.com/jira/browse/JBREM-1088">JBREM-1088</ulink>: If the server hostname DNS mapping was not available at the client during a <methodname>org.jboss.remoting.Client.connect()</methodname> call, the <methodname>org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName</methodname> produces a <exceptionname>java.net.UnknownHostException</exceptionname> in relation to the hostname. However when the method <methodname>org.jboss.remoting.transport.socket.MicroSocketClientInvoker(InvokerLocator locator, Map configuration)</methodname> is called the exception is captured and then displayed using <methodname>throw new RuntimeException(ex.getMessage())</methodname>. By displaying the exception in this way, information important in understanding the cause of the exception, is lost. This has been rectified by changing <methodname>throw new RuntimeException(ex.getMessage());</methodname> to <methodname>throw new RuntimeExc!
 eption(ex.getMessage(), ex);</methodname>, enabeling the actual exception content to be displayed to the user.
+									<ulink url="http://jira.jboss.com/jira/browse/JBREM-1088">JBREM-1088</ulink>: If the server hostname DNS mapping was not available at the client during a <methodname>org.jboss.remoting.Client.connect()</methodname> call, the <methodname>org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName</methodname> produces a <exceptionname>java.net.UnknownHostException</exceptionname> in relation to the hostname. However when the method <methodname>MicroSocketClientInvoker(InvokerLocator locator, Map configuration)</methodname> is called the exception is captured and then displayed using <methodname>throw new RuntimeException(ex.getMessage())</methodname>. By displaying the exception in this way, information important in understanding the cause of the exception, is lost. This has been rectified by changing <methodname>throw new RuntimeException(ex.getMessage());</methodname> to <methodname>throw new RuntimeException(ex.getMessage(), ex);</method!
 name>, enabeling the actual exception content to be displayed to the user.
 								</para>
 							</listitem>
 							<listitem>
@@ -589,9 +602,30 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1873">JBPAPP-1873</ulink>: When the <parameter>LIMIT_BUFFER</parameter> parameter was set to <code>true</code> an <exceptionname>ArrayIndexOutOfBoundsException</exceptionname> would occur. The <filename>BodyContentImpl.java</filename> file has been updated to correct this bug by removing the <varname>bufferSizeSave</varname> variable and removing the case where the <varname>writer</varname> variable isn't null. To replace these a case has been written to execute the <methodname>clearBody</methodname> method when the <varname>writer</varname> variable is equal to null. By implementing these changes the <classname>JspWriter</classname> buffer size and remaning bytes are calculated correctly, removing the <exceptionname>ArrayIndexOutOfBoundsException</exceptionname>.
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1874">JBPAPP-1874</ulink>: The JBoss Web component of the Enterprise Application Platform has been upgraded to version 2.0.0.CP10. A list of the included fixes is as follows:
 						</para>
-					</listitem>
+						<itemizedlist>
+							<listitem>
+								<para>
+									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1992">JBPAPP-1992</ulink>: Apache Tomcat 5 and 6 did not properly handle double quote (<emphasis>"</emphasis>) characters and the encoded backslash (%5C) sequences in cookie values. These bugs may have allowed for sensitive information such as session IDs to be leaked to remote attackers and permit session hijack attacks. This has been rectified by the modification of <filename>ApplicationContext.java</filename> to generate a <exceptionname>MalformedURLException</exceptionname> if a path starts with an encoded backslash and the modification of <filename>ServerCookie.java</filename> to escape double quote characters. (CVE-2007-5333)
+								</para>
+							</listitem>
+							<listitem>
+								<para>
+									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1950">JBPAPP-1950</ulink>: After the <methodname>HttpServletResponse.reset</methodname> method was executed, any subsequent calls to <methodname>response.setContentType</methodname> or <methodname>response.setCharacterEncoding</methodname> had no effect on the content type. This latest release incorporates a fix that allows the  <methodname>response.setContentType</methodname> and <methodname>response.setCharacterEncoding</methodname> methods to function correctly after a <methodname>HttpServletResponse.reset</methodname> call and modify the content type. To achieve this outcome the following method executions have been added to the <methodname>reset()</methodname> method of the <classname>Response</classname> class:
+								</para>
+<programlisting>
+usingOutputStream = false;
+usingWriter = false;
+isCharacterEncodingSet = false;
+</programlisting>
+							</listitem>
+							<listitem>
+								<para>
+									<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1873">JBPAPP-1873</ulink>: When the <parameter>LIMIT_BUFFER</parameter> parameter was set to <code>true</code> an <exceptionname>ArrayIndexOutOfBoundsException</exceptionname> would occur. The <filename>BodyContentImpl.java</filename> file has been updated to correct this bug by removing the <varname>bufferSizeSave</varname> variable and removing the case where the <varname>writer</varname> variable isn't null. To replace these a case has been written to execute the <methodname>clearBody</methodname> method when the <varname>writer</varname> variable is equal to null. By implementing these changes the <classname>JspWriter</classname> buffer size and remaning bytes are calculated correctly, removing the <exceptionname>ArrayIndexOutOfBoundsException</exceptionname>.
+								</para>
+							</listitem>
+						</itemizedlist>
 				</itemizedlist> 
 				</para>
 		</formalpara>
@@ -863,6 +897,11 @@
 					</listitem>
 					<listitem>
 						<para>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1797">JBPAPP-1797</ulink>: Transient entities could be inserted twice when a merge was performed. To correct this bug the <filename>DefaultMergeEventListener.java</filename> file has been updated to use the new <classname>CopyCache</classname> class. Within the <filename>DefaultMergeEventListener.java</filename> file, logic has been added to retrieve transient entities and retry a merge once if an error is encountered. Following this, if the merge continues unsuccessfully a <exceptionname>TransientObjectException</exceptionname> will be generated. The <classname>CopyCache</classname> class has been created to be the <varname>Map</varname> implementation used by <classname>DefaultMergeEventListener</classname> in order to keep track of entities and the copies that are being merged into the session. This implementation also tracks whether a an entity in the <classname>CopyCache</classname> is included in the merge.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1748">JBPAPP-1748</ulink>: When merging read-only entities that had the <varname>@Immutable</varname> annotation included the following failure would occur:
 						</para>
 <screen>	
@@ -887,6 +926,11 @@
 					</listitem>
 					<listitem>
 						<para>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1564">JBPAPP-1564</ulink>: The SQL <methodname>trim</methodname> function and support for <property>mod</property> and <property>bit_length</property> were not present in the Sybase Dialect. This release sees these avaliable for use within the <filename>SybaseASE15Dialect</filename>.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1563">JBPAPP-1563</ulink>: The SQL functions <function>mod</function>, <function>bit_length</function> and <function>trim</function> caused faulures in the <classname>ASTParserLoadingTest</classname> because they were not implemented in the Sybase Dialect. The Sybase Dialect has now been updated to import the <classname>org.hibernate.dialect.function.AnsiTrimEmulationFunction</classname> function and implement the <function>mod</function>, <function>bit_length</function> and <function>trim</function> functions.
 						</para>
 					</listitem>
@@ -948,6 +992,14 @@
 				<itemizedlist>
 					<listitem>
 						<para>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1992">JBPAPP-1992</ulink>: Apache Tomcat 5 and 6 did not properly handle double quote (<emphasis>"</emphasis>) characters and the encoded backslash (%5C) sequences in cookie values. These bugs may have allowed for sensitive information such as session IDs to be leaked to remote attackers and permit session hijack attacks. This has been rectified by the modification of <filename>ApplicationContext.java</filename> to generate a <exceptionname>MalformedURLException</exceptionname> if a path starts with an encoded backslash and the modification of <filename>ServerCookie.java</filename> to escape double quote characters. (CVE-2007-5333)
+						</para>
+						<para>
+							This bug fix is part of the JBoss Web 2.0.0.CP10 upgrade.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1961">JBPAPP-1961</ulink>: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced <exceptionname>Denial of Service</exceptionname> attacks on a server that accpets XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
 						</para>
 						<para>
@@ -1021,6 +1073,11 @@
 							forcing the <filename>build.xml</filename> file to use Java 1.4.
 						</para>
 					</listitem>
+					<listitem>
+						<para>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1685">JBPAPP-1685</ulink>: Apache-slide has been upgraded to version 2.1.jdk15-brew. In this change is the renaming of <filename>jakarta-slide-webdavlib.jar</filename> to <filename>webdavlib.jar</filename> and the <filename>commons-httpclient.jar</filename> has been removed from the distribution because it was dependant on an unincluded <filename>commons-codec.jar</filename>. Removal of the <filename>commons-httpclient.jar</filename> file does not impact correct functioning of the JBoss Enterprise Application Platform.
+						</para>
+					</listitem>
 				</itemizedlist>
 			</para>
 		</formalpara>
@@ -1053,6 +1110,20 @@
 			<title>Hibernate Known Issues</title>
 			<para>
 				<itemizedlist>
+					<listitem>
+						<para>
+							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1709">JBPAPP-1709</ulink>: The JPA spec defines the constant with a value that has a typo in the class name:
+						</para>
+<programlisting>
+javax.persistence.Persistence.PERSISTENCE_PROVIDER = "javax.persistence.spi.PeristenceProvider"
+</programlisting>
+						<para>
+							The version of <filename>ejb3-persistence.jar</filename> released in EAP is non-compliant with the JPA spec because it sets the correct classname (without the typo) for this constant. 
+						</para>
+						<para>
+							Javadoc for <methodname>javax.persistence.Query.getSingleResult()</methodname> says that the <exceptionname>EntityNotFoundException</exceptionname> will be generated if there is no result. The Javadoc should have mentioned the <exceptionname>NoResultException</exceptionname> instead.
+						</para>
+					</listitem>
 				<!--	<listitem>
 						<para>
 							<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1613">JBPAPP-1613</ulink>: Null values for columns mapped as boolean in Hibernate, are persisted as zero instead of null. When the <methodname>PreparedStatement.setNull( index, java.sql.Types.BIT ) </methodname> method is executed in the Sybase environment, Sybase JDBC converts the null value to a zero because Sybase does not allow null bit columns. 




More information about the jboss-cvs-commits mailing list