[jboss-cvs] JBossAS SVN: r83038 - projects/docs/enterprise/4.3.4/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jan 19 00:53:13 EST 2009
Author: irooskov at redhat.com
Date: 2009-01-19 00:53:13 -0500 (Mon, 19 Jan 2009)
New Revision: 83038
Modified:
projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
Log:
updated release notes with new JIRA
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-19 04:13:30 UTC (rev 83037)
+++ projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml 2009-01-19 05:53:13 UTC (rev 83038)
@@ -277,8 +277,90 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-">JBPAPP-</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1615">JBPAPP-1615</ulink>: The JBoss Messaging component of the EAP has been upgraded to version 1.4.0.SP3-CP05. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <literal>default</literal> profile for JBoss without any reconfiguration uses the <classname>ClusteredConnectionFactory</classname> with a non-clustered post-office, however warnings would be loged about this behavior when the log messages should be reduced from a <varname>WARN</varname> level to an <varname>INFO</varname> level. The upgrade to this version of JBoss Messaging sees this implemented within the log.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <classname>ClusterViewUpdateTest</classname> was broken and did not work correctly in previous releases with the cause being that the expected time until failure detection for some clustering tests was too long. In order to correct this the values for <varname>validatorPingPeriod</varname> and <varname>validatorPingTimeout</varname> have been changed to be 2 seconds each, combining to 4 seconds as the total time until expected failure detection.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
@@ -462,6 +544,11 @@
<title>JBoss Hibernate</title>
<para>
<itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1582">JBPAPP-1582</ulink>:
+ </para>
+ </listitem>
<!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1556">JBPAPP-1556</ulink>:
@@ -582,7 +669,7 @@
<itemizedlist>
<listitem>
<para>
- <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>&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.
+ <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>&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. (CVE-2009-0027 )
</para>
</listitem>
</itemizedlist>
@@ -748,67 +835,67 @@
</listitem>
<listitem>
<para>
-
+ The <classname>BindingValidator</classname> would generate a <exceptionname>ConverterException</exceptionname> instead of a <exceptionname>ValidatorException</exceptionname>. For this update, <classname>BindingValidator</classname> has been modified to generate the correct exception; <exceptionname>ValidatorException</exceptionname>.
</para>
</listitem>
<listitem>
<para>
-
+ The cause of a <classname>PostConstruct</classname> exception within the <classname>BeanBuilder</classname> was not communicated to the user correctly. To correct the issue so that no information is hidden from the user, the <exceptionname>ManagedBeanCreationException</exceptionname> has been updated to provide more information about the cause of the exception.
</para>
</listitem>
<listitem>
<para>
-
+ An issue was present that would cause majarra to execute <filename>faces-config.xml </filename> initialization files twice, creating duplicate operations. This was caused since a record was not kept of which files had been intialized and which had not. File initialization tracking has been implemented to correct this issue and this has seen the modification of the following files: <filename>ConfigManager.java</filename>, <filename>ConfigureListener.java</filename>, <filename>WebConfiguration.java</filename>, <filename>ConfigurationResourceProvider.java</filename>, <filename>MetaInfResourceProvider.java</filename>, <filename>RIConfigResourceProvider.java</filename> and <filename>WebResourceProvider.java</filename>.
</para>
</listitem>
<listitem>
<para>
-
+ The <classname>com.sun.faces.renderkit.ApplicationObjectInputStream</classname> extends the functionality of <classname>java.io.ObjectInputStream</classname> but failed to preserve the functionality as <classname>com.sun.faces.renderkit.ApplicationObjectInputStream</classname> would fail when primitives were used, unlike the <classname>java.io.ObjectInputStream</classname> class which contains a special case to handle such a case. This would cause problems for <literal>UIComponents</literal>. <filename>ApplicationObjectInputStream.java</filename> has been updated to explicitly handle primitive cases and catch the <exceptionname>ClassNotFoundException</exceptionname> which may be generated.
</para>
</listitem>
<listitem>
<para>
-
+ <classname>com.sun.faces.renderkit.html_basic.OutputLinkRenderer</classname> did not encode parameters correctly, missing the <literal>URLEncoding</literal>. <literal>URLEncoding</literal> has been added, correcting this bug, along with the parameter names.
</para>
</listitem>
<listitem>
<para>
-
+ The <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> did not allow for empty <varname>columnClasses</varname> when generating columns from user unput. The issue was realizing when to create numerious columns rather just one; for instance if the user input <literal>foo, </literal> with a trailing space then the expected output would be one column with the name <literal>foo</literal> and another empty column. This was not the case though, as <literal>foo, </literal> would generate just one column with <literal>foo, </literal> in its entirety as the column name, instead of spliting the columns on the comma. This behaviour has now been corrected so that <classname>com.sun.faces.renderkit.html_basic.BaseTableRenderer</classname> no generates columns correctly, and in order to achieve this the following files have been updated: <filename>BasetableRenderer.java</filename>, <filename>GridRenderer.java</filename> and <filename>TableRenderer.java</!
filename>.
</para>
</listitem>
<listitem>
<para>
-
+ The <classname>com.sun.faces.renderkit.html_basic.MenuRenderer</classname> class did not correctly differentiate between <literal>Objects</literal>; for instance the different between <literal>Boolean</literal> and <literal>boolean</literal>, noting the capitalization of the first. The error was with the logic in <classname>UISelect</classname> and <classname>MenuRenderer</classname>. To correct this, proper use of the converter for these classes has been implemented to deal with Objects correctly.
</para>
</listitem>
<listitem>
<para>
-
- </para>
+ <classname>com.sun.faces.lifecycle.RestoreViewPhase</classname> called <methodname>DebugUtil.printTree</methodname> after restoring the view if debugging was enabled, causing incorrect initialization of calls when a listbox is being used and returning an incorrect value in the <classname>RenderResponse</classname> phase. Method calls have been restructured with the removal of references to the <methodname>DebugUtil.printTree()</methodname> method from <filename>ViewHandlerImpl.java</filename> and <filename>RestoreViewPhase.java</filename> and <filename>RenderResponsePhase.java</filename> has been modified to call <methodname>DebugUtil.printTree</methodname> (if <varname>FINEST</varname> logging is enabled) at the end of the <classname>RenderResponse</classname> phase, fixing the issue (with the above changes also) and providing a more accurate view of the tree. </para>
</listitem>
<listitem>
<para>
-
+ <literal>CGLIB Enhanced UIComponents</literal> in a component tree would return a value of null for their class when calling <methodname>getPackage()</methodname> causing <classname>HtmlInputText.handleAttribute</classname> to fail as it relies on a not-nulll value. This issue has been corrected by ignoring a returned value of null from the <methodname>getPackage()</methodname> method for every instance in the codebase.
</para>
</listitem>
<listitem>
<para>
-
+ The <classname>UIComponentBase</classname> did not allow for the children of a tree to be iterated through in reverse order using a list iterator as it would produce an <exceptionname>IndexOutOfBoundsException</exceptionname> when the execution tries to calculate the size of the children. <methodname>ChildrenListIterator</methodname> method has been modified within the <classname>UIComponentBase</classname> class by changing the line of code <code>if ((index < 0) || (index >= list.size())) { </code> to <code>if ((index < 0) || (index > list.size())) {</code>.
</para>
</listitem>
<listitem>
<para>
-
+ Renderer kits for <filename>faces-config.xml</filename> were processed out of order depending on if <literal>ICEfaces</literal> or <literal>Mojara 1.2_09</literal> is in use. This occured due to containing all renderer DOM nods in a list associated with a namespace. This was done so that the renderer nodes could then be processed prior to the <literal>RenderKits</literal> being created and the nodes could be processed using the proper namespace. However, by placing all the renderers into this list, we lost the document ordering. The issue has been fixed by associating the renderer nodes with their owning document and processed in the parsing order.
+
</para>
</listitem>
<listitem>
<para>
-
+ The <methodname>Class.getPackage()</methodname> method calls to synchronized methods, inhibiting scalability if the method has to be repeatedly executed. Use of the <methodname>Class.getPackage()</methodname> method has now been removed from <filename>UIComponent.java</filename>, <filename>RenderKitUtils.java</filename> and <filename>HtmlComponentGenerator.java</filename>. Instead, the class name is now checked if it starts with the package name that is of interest, <classname>javax.faces.component.</classname>. This includes the components that are generated by the <classname>HtmlComponentGenerator</classname> since they are packaged in <classname>javax.faces.component.html</classname>.
</para>
</listitem>
<listitem>
<para>
-
+ A bug presented itself in the <classname>RenderKitUtils</classname> class when a semicolon (<code>;</code>) followed a forward-slash (<code>/</code>) in a header Accept value (for instance: <code>text/;q=0.5</code>). To rectify this issue the <classname>RenderKitUtils</classname> class has been updated to assume <code>*</code> as the subtype for an Accept header that contains no subtype.
</para>
</listitem>
</itemizedlist>
More information about the jboss-cvs-commits
mailing list