[jboss-cvs] JBossAS SVN: r83130 - projects/docs/enterprise/4.2.6/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Jan 21 00:14:27 EST 2009
Author: irooskov at redhat.com
Date: 2009-01-21 00:14:27 -0500 (Wed, 21 Jan 2009)
New Revision: 83130
Modified:
projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml
Log:
updated Release Notes with new JIRA
Modified: projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml
===================================================================
--- projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml 2009-01-21 04:35:17 UTC (rev 83129)
+++ projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml 2009-01-21 05:14:27 UTC (rev 83130)
@@ -278,8 +278,20 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-">JBPAPP-</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1533">JBPAPP-1533</ulink>: The JBoss Cache component of the EAP has been upgraded to version 1.4.1.SP11. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <classname>JDBCCacheLoader</classname> implementation did not work with Sybase as it would try to set a null <varname>BLOB</varname> column which is unsupported within Sybase. To correct this the <filename>JDBCCacheLoader.java</filename> file has been updated so that the Sybase Driver sets a null <varname>LONGVARBINARY</varname> value, allowing the <classname>JDBCCacheLoader</classname> implementation to work correctly.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <classname>JDBCExtCacheLoader</classname> did not handle persistent state transfer correctly since the <methodname>JDBCExtCacheLoader.storeState()</methodname> method would use avaliable bytes on the <classname>MarshalledValueInputStream</classname> rather than on the <classname>ByteArrayInputStream</classname> when storing the persistent state. This was an issue because the <classname>MarshalledValueInputStream</classname> always returns a null value, meaning the persistent state was never written. In fixing this issue the <filename>JDBCExtendedCacheLoader.java</filename> file has been modified so that it specifies to check for avaliable space on the <classname>ByteArrayInputStream</classname>.
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
@@ -290,8 +302,70 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-">JBPAPP-</ulink>:
+ <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>
+ During occurances of the server being under heavy load, an <exceptionname>IllegalStateException</exceptionname> would occur within the <methodname>ConnectorValidator.run()</methodname> method because further synchronization on the <varname>lock</varname> variable was necessary. This issue was fixed during the rectification of the above problem.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A synchronization error within the <classname>MarshalFactory</classname> was allowing a subsystem to add a marshaller at the same time as EJB3 was trying to extract one causing users to receive an <exceptionname>InvalidMarshallingResource</exceptionname> exception; this also applied to unmarshallers. The error has been fixed by updating the <filename>jboss-remoting.jar</filename> file to include synchronized static Maps within the <classname>MarshalFactory</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <classname>SocketServerInvoker</classname> had an issue when shutting down <varname>ServerThreads</varname> causing a user to possibly receive an invocation to a closed <classname>SocketServerInvoker</classname> on the client side, causing an <exceptionname>InvalidStateException</exceptionname>. Allowing this exception would cause a clustered EJB3 system to generate a <exceptionname>UndeclaredThrowableException</exceptionname> instead of trying alternative servers. To allow for alternatives to be attempted, an optional behavior of allowing the <classname>MicroRemoteClientInvoker</classname> to interpret an <exceptionname>InvalidStateException</exceptionname> as a <exceptionname>CannotConnectException</exceptionname>, allowing for other servers to be attempted.
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
@@ -310,21 +384,29 @@
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1470">JBPAPP-1470</ulink>: When using APR (Apache Portable Runtime) on any operating system other than those which use the Linux Kernal 2.4 or newer, the <parameter>deferAccept</parameter> option would be set to false in the <methodname>AprEndpoint</methodname>. This may lead to a <exceptionname>NullPointerException</exceptionname> as the <methodname>accepter</methodname> thread starts to process a request while also calling for a <methodname>poller</methodname> before initialization. The issue has been resolved by moving the <methodname>acceptor</methodname> threads to being executed last when starting the <methodname>AprEndpoint</methodname>.
</para>
</listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1334">JBPAPP-1334</ulink>: The JBoss Web component of the EAP has been upgraded to version 2.0.0-6.CP09. A list of the included fixes is as follows:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ If a war deployment included its own version of <filename>xalan.jar</filename> and <filename>xercesImpl.jar</filename> in <filename>WEB-INF/lib</filename>, the JBossWeb servlet container classloader returns JBoss provided version of the <literal>SAXParser</literal> from <methodname>SAXParserFactory.newInstance().newSAXParser()</methodname> rather than the version provided in the war deployment. To fix this bug the <filename>WebAppClassLoader.java</filename> has been updated to ensure the correct parser is used.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
</itemizedlist>
</para>
</formalpara>
- <formalpara>
+ <!-- <formalpara>
<title>JBoss Web Services</title>
<para>
<itemizedlist>
- <listitem>
- <para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1552">JBPAPP-1552</ulink>: When deploying JBoss Web Services within EAP without internet access, <classname>JBossWSEntityResolver</classname> would not resolve any schemas causing Web Services for Remote Portlets (WSRP) to produce an error. This issue has been fixed by modifying <classname>JBossWSEntityResolver</classname> within <filename>WSDL11Reader.java</filename> to resolve schemas locally when an internet connection is unavaliable.
- </para>
- </listitem>
+
</itemizedlist>
</para>
- </formalpara>
+ </formalpara> -->
<formalpara>
<title>JBoss Seam</title>
<para>
@@ -334,6 +416,16 @@
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP-1553</ulink>: When the <methodname>parseRequest()</methodname> method of the <classname>org.jboss.seam.web.MultipartRequest</classname> class uploaded a large file, there were occurances when this would cause an endless loop and use 100% of the computers CPU. In order to break out of the loop, a <varname>loopCounter</varname> has been implemented within the <filename>MultipartRequest.java</filename> file.
</para>
</listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1494">JBPAPP-1494</ulink>: The portal example that was previously included with the Seam EAP distribution has been removed in order to avoid confusion that Seam 1.2.1 included with the EAP supports portal.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1044">JBPAPP-1044</ulink>: After basic interaction with the Seam examples <filename>chatroom</filename>, <filename>mail</filename>, <filename>registration</filename>, <filename>booking</filename> and <filename>dvdstore</filename> would generate a <exceptionname>NullPointerException</exceptionname> during undeployment. In correcting this issue, the <filename>RootInterceptor.java</filename> file was updated to check if an applications context still active upon undeployment and deal with this appropriately.
+ </para>
+ </listitem>
</itemizedlist>
</para>
</formalpara>
@@ -343,6 +435,16 @@
<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>:
+ </para>
+ </listitem> -->
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1529">JBPAPP-1529</ulink>: The composite primary key of 765 bytes fails within the unit test for Sybase, as it exceeds the maximum index length of 600 bytes. In order to rectify this issue, a hard coded length of 32 bytes is now in place for the compasite primary key ID within the <filename>UserGroup.hbm.xml</filename> file.
</para>
</listitem>
@@ -426,6 +528,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP-1251</ulink>: Filters that were enabled for Hibernate did not apply to update and delete Hibernate Query Language (HQL) statements. In correcting this bug numerious files have been updated to ensure that the filters work correctly. This fix is related to JBPAPP-1250 below.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1250">JBPAPP-1250</ulink>: When creating queries with subqueries in Hibernate, any added filters would only apply to the top-level of the query and not to any subquery component or beneath. The Criteria code and HQL code asociated with this has undergone significant re-tooling to allow filters to work appropriatly with subqueries and extent as far as the Hibernate Query Language does.
</para>
<para>
@@ -451,7 +558,7 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-">JBPAPP-</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1565">JBPAPP-1565</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>
@@ -495,11 +602,58 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1534">JBPAPP-1534</ulink>:The JDBCCacheLoader didn't work with Sybase as it tried to set a null <varname>BLOB</varname> (Binary Large OBject) column which is unsupported in Sybase. To correct this the <filename>JDBCCacheLoader.java</filename> and <filename>AdjListJDBCCacheLoader.java</filename> files have been updated to select the Sybase Driver if Sybase is to be used, ensuring that null values are set as <varname>LONGVARBINARY</varname> rather than <varname>BLOB</varname>.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1534">JBPAPP-1534</ulink>: The JDBCCacheLoader didn't work with Sybase as it tried to set a null <varname>BLOB</varname> (Binary Large OBject) column which is unsupported in Sybase. To correct this the <filename>JDBCCacheLoader.java</filename> and <filename>AdjListJDBCCacheLoader.java</filename> files have been updated to select the Sybase Driver if Sybase is to be used, ensuring that null values are set as <varname>LONGVARBINARY</varname> rather than <varname>BLOB</varname>.
</para>
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1532">JBPAPP-1532</ulink>: The JGroups clustering component of the EAP has been upgraded to version 2.4.5. A list of the included fixes is as follows:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The probe listener within JGroups still used the old default address of 224.0.0.75 instead of the new address of 224.0.75.75. The probe listener within JGroups has been updated with this release to use the correct default address.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The MPING protocol which sends a multicast ping over TCP contained cross-talk in Linux. the MPING protocol has since been corrected to eliminate cross-talk on the Linux platform.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A problem was encountered within JGroups when two distinct processes were setup on the same machine, each using a different stack with different UDP multicast addresses. The issue was that each process would not work correctly because of the other, as each process would receive incorrect datagrams in reference to the groups each joined. To correct this the <classname>MulticastSocket</classname> constructor is now used in combination with a <varname>SocketAddress</varname> when JGroups is used on the Linux platform.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <literal>Gossip Router</literal> component of JGroups provided options to set <literal>backlog</literal>, <literal>socket read timeout</literal> and <literal>socket linger timeout</literal> within the code, however these options are not avaliable via the command line. This update of the JGroups component, now includes the availability of these options to be set through the command line.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Within the <literal>Gossip Router</literal> component of JGroups <methodname>Math.min</methodname> was used in calculating the socket linger timeout which caused incorrect results since this meant that the socket linger timeout would always be 1. <literal>Gossip Router</literal> has been updated to instead use <methodname>Math.max</methodname> in the calculation of the socket linger timeout.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <classname>RouterStub</classname> and <classname>GossipRouter</classname> classes have the <varname>setSoLinger</varname> value set incorrectly to use a seconds value when <varname>setSoLinger</varname> uses millisecond values. This meant that a value of 500 was 500 seconds rather than 500 milliseconds. The <classname>RouterStub</classname> class has had its <varname>setSoLinger</varname> corrected and the <classname>GossipRouter</classname> class has had the <varname>setSoLinger</varname> value corrected and timouts configurable.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1530">JBPAPP-1530</ulink>: The JCA adapter inflow did not roll back messages if a non-xa connection factory was being used within the JNDIProviderAdapter. In order to fix this issue the <filename>JmsServerSession.java</filename> file has been updated with added logic to the local transaction seperation strategy as to allow for non-xa sessions to be rolled back using transaction session.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1521">JBPAPP-1521</ulink>: The <classname>CleanShutdownInterceptor</classname> class would log a <exceptionname>GenericClusteringException</exceptionname> when the container had failed to shut down correctly or failed to start correctly and because of this behavior the error message displayed because of the exception should be updated to indicate that it may be an issue with the container failing to start instead of only failing to shut down. In this latest EAP update, the error message has been updated to reflect both situations which may be the cause of the exception.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1479">JBPAPP-1479</ulink>: Within the different distributions of the EAP that are 4.2 and 4.3, both the <filename>JBossMQ</filename> and <filename>JBoss Messaging</filename> application policies have been present within the <filename>login-config.xml</filename> file, when <filename>JBossMQ</filename> is only included in the 4.2 distribution and <filename>JBoss Messaging</filename> is similarly only included in the 4.3 distribution.
</para>
<para>
@@ -528,6 +682,18 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1289">JBPAPP-1289</ulink>: The JBoss JAXR component of the EAP has been upgraded to version 1.2.0.SP2. A list of the included fixes is as follows:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ In the <filename>org.jboss.jaxr.juddi.JUDDIServlet</filename> and <filename>org.jboss.jaxr.juddi.transport.SaajTransport</filename> files the namespace value for <varname>xml:lang</varname> contained <literal>http://www.w3.org/TR/REC-xml/</literal>, which caused an exception within the metro stack. The namespace value should instead be null and this has been applied for this JAXR update.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1275">JBPAPP-1275</ulink>: The Xalan part of the EAP has been upgraded from version 2.7.0 to 2.7.0.patch02. This upgrade removes the circumstance where an application which heavily used Xalan within large multi-threaded environments would encounter blocking situatinos.
</para>
</listitem>
@@ -538,11 +704,149 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1249">JBPAPP-1249</ulink>: The JSF component of the EAP has been upgraded to version 1.2_10. A list of the included fixes is as follows:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ A mixed EL expression ending with a literal failed to parse as a managed bean property value. The <filename>BeanBuilder.java</filename> file was updarted with the removal of <code>ELUtils.getScope(this.expressionString, segment);</code> in order to fix this issue.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <methodname>LifecycleImpl</methodname> and <methodname>RestoreViewPhase</methodname> forced the <methodname>responseComplete()</methodname> method for the status of an existing view. To correct this problem the <filename>RestoreViewPhase.java</filename> file has been edited with the code <code>facesContext.responseComplete();</code> removed and replaced with <code>facesContext.renderResponse();</code>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ For a <h:dataTable> tag which does not set the <varname>var</varname> attribute, if the UIData component is created using a binding and calls the <methodname>setVar()</methodname> method to set the <varname>var</varname> attribute, it would be overwritten as a null value by the <h:dataTable> tag. This bug has been fixed by modifying the <filename>HtmlTaglib21Generator.java</filename> file so that component properties are not set if the tag attribute has not been set.
+ </para>
+ </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>
+ <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>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1224">JBPAPP-1224</ulink>: Attribute default values in EJB were not set when in use with <literal>@Service</literal> and <literal>XMBean XML</literal> . In order to correct this the behavior has been re-written to improve the mimicking of <classname>ServerCreator</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1170">JBPAPP-1170</ulink>: When the <methodname>getMBeanInfo</methodname> method is called within <classname>MBeanServerImpl</classname> and <classname>RawDynamicInvoker</classname>, the underlying exception to <exceptionname>NotCompliantMBeanException</exceptionname> is not expressed to the user. <filename>RawDynamicInvoker.java</filename> has now been updated to provide this useful information to the user.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1099">JBPAPP-1099</ulink>: The <filename>commons-beanutils.jar</filename> file within the EAP had the incorrect version in the <filename>manifest.mf</filename> file. Through the course of correcting this bug, it was found that the <literal>beanutils</literal> component was outdated and a newer version contained manu advantages. In this update to the EAP <literal>beanutils</literal> has been upgraded to version 1.8.0, which sees the significant improvement that fixes a memory leak caused by a circular reference concerning the <classname>WeakHashMap</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1002">JBPAPP-1002</ulink>: Bean Managed Transactions (BMT) Stateful Session Beans used to be logged when transactions were not completed between invocations. However this was an error as BMT Stateful Session Beans are allowed to have this occurance and so this logging measure has been removed in this EAP update.
</para>
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-996">JBPAPP-996</ulink>: Discrepancies existed between the port schemes within the <filename>sample-bindings.xml</filename> file. These include:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The remoting connectors were inserted in different places within the ports definition sections, making the comparison of the sections more difficult than was necessary.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <literal>ports-03</literal> section was missing the <literal>EJB remoting connector</literal> and the <literal>remoting connector</literal> sections.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>mq</literal> was used in the name property of the <varname>HAJNDIJMSProvider</varname> instead of <literal>jms</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <literal>ports-01</literal>, <literal>ports-02</literal>, and <literal>ports-03</literal> schemes defined the <varname>timeout</varname> attribute twice in the <literal>JBoss Messaging</literal> section:
+
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The above issues have been fixed appropriately in this update.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-713">JBPAPP-713</ulink>: A Classloader leak existed causing a <errorname>OutOfMemoryError: PermGen</errorname> error. To correct this issue the EAP now uses <filename>beanutils 1.8.0</filename> which fixes this <errorname>OutOfMemoryError</errorname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-529">JBPAPP-529</ulink>: JMX source code was being exposed to the user when a <exceptionname>HTTP Status 500</exceptionname> exception would occur. To correct this, an error page <filename>genericError.jsp</filename> has been created and is now displayed whenever a <exceptionname>HTTP Status 500</exceptionname> exception occurs.
</para>
</listitem>
More information about the jboss-cvs-commits
mailing list