Author: prabhat.jha(a)jboss.com Date: 2009-04-22 10:37:09 -0400 (Wed, 22 Apr 2009) New Revision: 13261 Added: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.ent docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.xml Modified: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Book_Info.xml Log: update identity version and some minor versioning fix Modified: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Book_Info.xml =================================================================== --- docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Book_Info.xml 2009-04-22 12:16:09 UTC (rev 13260) +++ docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Book_Info.xml 2009-04-22 14:37:09 UTC (rev 13261) @@ -3,8 +3,8 @@ ]> <articleinfo> - <title>Release Notes GA</title> - <subtitle>for Use with JBoss Enterprise Portal Platform 4.3</subtitle> + <title>Release Notes</title> + <subtitle></subtitle> <edition>1.0</edition> <pubsnumber>6</pubsnumber> <productname>JBoss Enterprise Portal Platform</productname> Added: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.ent =================================================================== --- docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.ent (rev 0) +++ docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.ent 2009-04-22 14:37:09 UTC (rev 13261) @@ -0,0 +1,3 @@ +<!ENTITY HOLDER "Red Hat, Inc"> +<!ENTITY YEAR "2008"> +<!ENTITY VERSION "4.3 CP01"> Added: docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.xml =================================================================== --- docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.xml (rev 0) +++ docs/enterprise/tags/Enterprise_Portal_Platform_4_3_GA_CP01/Read_Me/en-US/Release_Notes.xml 2009-04-22 14:37:09 UTC (rev 13261) @@ -0,0 +1,873 @@ +<?xml version="1.0"?> +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ +<!ENTITY % RH_ENTITIES SYSTEM "./Common_Config/rh-entities.ent"> +%RH_ENTITIES; +]> +<article id="JBEAP-Release-Notes"> + <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Book_Info.xml"/> + <section id="Introduction"> + <title> + Introduction + </title> + <para> + These release notes contain important information related to JBoss Enterprise Portal Platform &VERSION;. New features, known problems, resources, and other current issues are addressed here. + </para> + <section id="Overview"> + <title>Overview</title> + <para> + JBoss Enterprise Portal Platform facilitates the delivery of web-based composite applications and high-performance web presences. Through its agile, reusable framework, customers can minimize the cost and complexity of their web infrastructures. Its use of open standards mitigates the risk of vendor lock-in, ensuring compatibility. As an integral component of JBoss Enterprise Middleware, the large and vibrant JBoss.org developer community fosters its continued innovation and enterprise quality. And it's deployed on JBoss Enterprise Application Platform—the industry’s #1 J2EE-certified application platform ensuring performance, scalability, and a reliable and straightforward path to implementation. + </para> + <para> +JBoss Enterprise Application Platform is the next evolutionary step in open source enterprise software. It is a powerful tool for developing rich, high performance, Web 2.0 applications on a pure Java Platform. + </para> + <para> + JBoss Enterprise Application Platform provides complete compatibility with existing J2EE 1.4 enterprise Java applications. At the same time, almost all the key features and components defined in the Java EE 5.0 specification are supported. So your new enterprise Java applications can take immediate advantage of the Java EE 5.0's significantly simpler POJO-based programming model. + </para> + <para> + Further, by integrating best-of-breed open source frameworks such as JBoss Seam, Hibernate, Tomcat, and JBoss Cache the Platform takes advantage of innovations in the open source community. As well, JBoss Enterprise Application Platform is fully tested and supported by Red Hat, and is certified to work on many leading enterprise hardware and software products. + </para> + <para> + All of which means you can develop your new application taking advantage of Java EE 5.0 technologies immediately and with the confidence of knowing it will remain forward-compatible with future versions of the JBoss Platform. + </para> + </section> + </section> + <section id="New_Features"> + <title>New Features in JBoss Enterprise Portal Platform 4.3</title> + <section id="JSR-286"> + <title>Portlet 2.0 -JSR 286</title> + <para> + The main improvement of the Enterprise Portal Platform is the support of Portlet 2.0 specification which enables Inter Portlet Communication by sharing parameters and event support. + </para> + </section> + </section> + <section id="Component_Versions"> + <title>Component Versions</title> + <para> + This section details the versions of the components which create the Enterprise Portal Platform 4.3 that can be found in release on top of the components delivered by the Enterprise Application Platform 4.3.CP04. + </para> + <itemizedlist> + <listitem> + <para> + Identity Module 1.1.0 + </para> + </listitem> + <listitem> + <para> + Common Module 1.2.4 + </para> + </listitem> + <listitem> + <para> + Portlet Module 2.0.7 + </para> + </listitem> + <listitem> + <para> + Web Module 1.2.3 + </para> + </listitem> + <listitem> + <para> + CMS Module 1.2.5 + </para> + </listitem> + + <listitem> + <para> + JBoss Portlet Bridge 1.0.0.CR1 + </para> + </listitem> + </itemizedlist> + <note> + <para> + The Enterprise Portal Platform Server has been redefined for the enterprise market to a level where direct association to a community release can no longer be drawn. + </para> + </note> + </section> + <section id="Product-Support-and-License-Links"> + <title> + Product Support and License Website Links + </title> + <formalpara> + <title>Support Processes</title> + <para> + <ulink url="http://www.redhat.com/support/process/">http://www.redh... + </para> + </formalpara> + + <formalpara> + <title> + Production Support Scope of Coverage + </title> + <para> + <ulink url="http://www.redhat.com/support/policy/soc/production">ht... + </para> + </formalpara> + + + <formalpara> + <title> + Production Support Service Level Agreement + </title> + + <para> + <ulink url="http://www.redhat.com/support/policy/sla/production/">h... + </para> + </formalpara> + + <formalpara> + <title> + Developer Support Scope of Coverage + </title> + + <para> + <ulink url="http://www.redhat.com/support/policy/soc/developer/">ht... + </para> + </formalpara> + + <formalpara> + <title> + Developer Support Service Level Agreement + </title> + + <para> + <ulink url="http://www.redhat.com/support/policy/sla/developer/">ht... + </para> + </formalpara> + + <formalpara> + <title> + Product Update and Support Policy by Product + </title> + + <para> + <ulink url="http://www.redhat.com/security/updates/jboss_notes/">ht... + </para> + </formalpara> + + <formalpara> + <title> + JBoss End User License Agreement + </title> + + <para> + <ulink url="http://www.redhat.com/licenses/jboss_eula.html">http://... + </para> + </formalpara> + </section> +<!-- + <section id="Issues-fixed-in-this-release"> + <title> + Issues fixed in this release + </title> + + <para> + Following is a list of issues fixed in this release: + </para> + <formalpara> + <title>JBoss Messaging</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1615">JBPAPP-1...;: 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> + Client connection parameters were not passed to the JBoss Remoting layer, forcing Remoting to use default values instead of user configured values. In order to use the correct values, <filename>JMSRemotingConnection.java</filename> has been updated so that the <methodname>Client.addConnectionListener</methodname> method is used with <varname>listener</varname> and <varname>serverLocator.gerParameters()</varname> as parameters. + </para> + </listitem> + <listitem> + <para> + Messages which are sheduled for delivery in the future were not being removed correctly when the <methodname>removeAllMessages()</methodname> method was being called, causing the messages to bre requeued as soon as the application server or queue is restarted. <filename>ChannelSupport.java</filename> has been updated to import the <filename>TimeoutExt</filename> library in order to cast the timeout value to <filename>TimeoutExt</filename> in order to obtain the reference value via the <methodname>getTimeoutTarget()</methodname> method. With this new reference value information, the sheduled messages can be correctly removed from the queue. + </para> + </listitem> + <listitem> + <para> + There was an occurance where a user may deploy a clustered queue in a single node instead of in all the nodes and the failover process would not work because of this. When this occurred an <exceptionname>IllegalStateException</exceptionname> would be generated, however this was not considered enough of a prominent warning about not deploying clustered queues correctly. <filename>MessagingPostOffice.java</filename> has now been updated to log a warning which outlies that clustered destinations must be deployed on all nodes of a cluster, instead of generating an <exceptionname>IllegalStateException</exceptionname>. + </para> + </listitem> + <listitem> + <para> + The <classname>ClientAOPStackLoader</classname>, <classname>SecurityAspect.check()</classname> and <classname>ServerConnectionFactoryEndpoint</classname> needed to be able to optain TCL within a privileged block, otherwise an <exceptionname>AccessControlException</exceptionname> is produced. To fix this bug, the <methodname>setTCL</methodname>, <methodname>getTCL</methodname> and other TCL methods have been set within security blocks; this prevents access denied exceptions from <classname>ClientAOPStackLoader</classname>, <classname>SecurityAspect.check()</classname> and <classname>ServerConnectionFactoryEndpoint</classname>. + </para> + </listitem> + <listitem> + <para> + The logging of actions within JBoss Messaging did not include the logging of messages when they are moved to the expiry or dead letter queues as this was only logged at trace level. In order to add this enhanced level of logging, the <filename>ClientConsumer.java</filename> file has been updated to log warning messages and debug information pertaining to the move of messages to the expiry or dead letter queues; <filename>ServerSessionEndpoint.java</filename> has also been updated in the same mannor. + </para> + </listitem> + <listitem> + <para> + There was an error when a message was received under a XA tx and the JBoss Messaging XAResource is prepared but not committed, a message could be received by another consumer in another transaction while the first is still in progress. The correct behaviour is for JBoss Messaging to hold the message until the associated transaction is committed or rolled back, enabling duplication of message deliveries to be avoided. In the <filename>Delivery.java</filename> file, messages are now marked with a boolean value detailing if they are for delivery with a XA transaction and if this transaction is prepared and <filename>SimpleDelivery.java</filename> now implements this new information. + </para> + </listitem> + <listitem> + <para> + The <methodname>shutdownNow()</methodname> method was not synchronized and may cause a <exceptionname>NoSuchElementException</exceptionname> during runtime as a result. A synchronization block has been placed around the <methodname>shutdownNow()</methodname> code within <filename>OrderedExecutorFactory.java</filename>. + </para> + </listitem> + <listitem> + <para> + There was an issue with the <classname>org.jboss.jms.server.messagecounter.MessageCounter</classname> class not being serializable as it caused an <exceptionname>UndeclaredThrowableException</exceptionname>. <filename>MessageCounter.java</filename> has been updated to now import and implement the <literal>Serializable</literal> library and be given a <varname>serialVersionUID</varname>, allowing the <classname>org.jboss.jms.server.messagecounter.MessageCounter</classname> class to be serializable. + </para> + </listitem> + <listitem> + <para> + When the methods <methodname>unregisterSucker()</methodname> or <methodname>registerSucker()</methodname> was called a <exceptionname>ConcurrentModificationException</exceptionname> would be generated by the time the <literal>HashSet</literal> containing the <literal>suckers</literal> was iterated. The issue would present itself on clusters with a magnitude of nodes (for instance it appeared on a 8 node cluster but not a 4 node cluster). This bug was corrected by creating an iterator that used a private set of <literal>suckers</literal> for iteration through the <literal>HashSet</literal> of <literal>suckers</literal> in order to avoid the exception. + </para> + </listitem> + <listitem> + <para> + The bridge within JBoss Messaging would only retry connection creation to a remote destination after startup and if the remote provider was not available at startup, the bridge would fail to start. The <filename>Bridge.java</filename> and <filename>BridgeService.java</filename> files have undergone extensive modification and now the <literal>factory</literal> is set to the <literal>bridge</literal> which undertakes the lookup itself instead of looking up the destinations. + </para> + </listitem> + </itemizedlist> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>JBoss Cache</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1533">JBPAPP-1...;: 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> + </formalpara> + <formalpara> + <title>JBoss Remoting</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1531">JBPAPP-1...;: 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> + </formalpara> + <formalpara> + <title>JBoss Web</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1493">JBPAPP-1...;: An error would be shown on occassion by <emphasis>Internet Explorer</emphasis> because xml content would not be sent when <emphasis>PROPFIND</emphasis> requests were being used. This has been fixed by creating a new method within <filename>WebdavServlet.java</filename> that overrides the <methodname>DefaultServlet</methodname> implementation for servlet request processing and testing for input before launching the <methodname>DocumentBuilder</methodname>. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1470">JBPAPP-1...;: 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-1...;: 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> + <title>JBoss Web Services</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1552">JBPAPP-1...;: 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> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1449">JBPAPP-1...;: WSProvide would ignore a <literal>SOAPBinding</literal> declaration specified in the EJB3 stateless session bean. To correct this and allow <literal>SOAPBinding</literal> to work as expected the following files have been modified: <filename>WSDLGenerator.java</filename>, <filename>SOAPEndpoint.java</filename>, <filename>Constants.java</filename>, <filename>WSDLWriter.java</filename>, <filename>SOAPBindingTestCase.java</filename> and <filename>WSDL11Writer.java</filename>. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1439">JBPAPP-1...;: The component <emphasis>Xerces</emphasis> of JBoss Web Services has a feature that optimises the parsing of messages called <methodname>Deffered Node Expansion</methodname>.This defers node expansion until the nodes are accessed, improving performance where not all nodes need to be visited. However memory overheads are increased, which can be considerable for large messages. + </para> + <para> + This release grants the user an option to disable the <methodname>Deffered Node Expansion</methodname> feature and have all nodes expand. To achieve this the following system property needs to be set: + </para> +<programlisting> +-Dorg.jboss.ws.disable_deferred_node_expansion=true +</programlisting> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>JBoss Seam</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1553">JBPAPP-1...;: 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-1...;: 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-1...;: 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> + <formalpara> + <title>JBoss Hibernate</title> + <para> + <itemizedlist> + <important> + <para> + Hibernate Core has been updated to an enhanced 3.2.4.sp1.cp07 version. The following issues represent the changes for this version. + </para> + </important> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1...;: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existance of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection. + </para> + <para> + <filename>AbstractEntityPersister.java</filename> has been updated to execute a prepared statement on the result set and after calculating the <varname>propValue</varname> the result set is closed if it is not null; ensuring that no leak can occur. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1582">JBPAPP-1...;: + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1524">JBPAPP-1...;: The Sybase functions <methodname>second()</methodname>, <methodname>minute()</methodname>, <methodname>hour()</methodname> and <methodname>extract()</methodname> caused a <exceptionname>GenericJDBCException</exceptionname> when used. Moving these functions from the <filename>SQLServerDialect.java</filename> file to the <filename>SybaseDialect.java</filename> file allows for these functions to work correctly. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1...;: Sybase does not support the opperation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both opperate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1496">JBPAPP-1...;: A memory leak existed because of an unclosed <emphasis>ResultSet</emphasis> when using the <emphasis>Identity</emphasis> generator option. To close the memory leak, the <emphasis>ResultSet</emphasis> is checked to make sure it is closed before returning the generated itentity value. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1480">JBPAPP-1...;: Hibernate would attempt to read from an invalid column in the collection result set when the following conditions were present: + </para> + <itemizedlist> + <listitem> + <para> + Instances of a subclass were contained in a collection. + </para> + </listitem> + <listitem> + <para> + The subclasses were single-table and used a &lt;join&gt; (table-per-subclass with discriminator). + </para> + </listitem> + <listitem> + <para> + The &lt;join&gt; portion of the subclass contained at least 3 of its own columns. + </para> + </listitem> + <listitem> + <para> + The &lt;join&gt; tables were fetched by select and not the default method for this task. + </para> + </listitem> + </itemizedlist> + <para> + To fix this isue the <filename>AbstractEntityPersister.java</filename> file was updated so that the <varname>columnNumber</varname> variable is passed to the <methodname>subclassColumnSelectableClosure</methodname> method instead of an increment of the for loop variable <varname>i</varname>. + </para> + <para> + <filename>CollectionTest.java</filename> has also been updated and <filename>Animal.java</filename>, <filename>Mammal.java</filename>, <filename>Zoo.hbm.xml</filename> and <filename>Zoo.java</filename> have been added for testing purposes. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1467">JBPAPP-1...;: A <exceptionname>PropertyValueException</exceptionname> would occur when merging a detached instance of a <classname>One</classname> class that contains a new <classname>Many</classname> class instance and if and only if the <classname>One</classname> class was previously loaded as a proxy during the same transaction. The files <filename>StatefulPersistenceContext.java</filename>, <filename>BackrefPropertyAccessor.java</filename>, <filename>BackrefTest.java</filename> and <filename>Child.java</filename> have been updated to check for the proxy issue in the mergining and once the proxy entity is found the <methodname>mergeMap</methodname> is updated to deal with this eventuality. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1365">JBPAPP-1...;: A bug existed within Hibernate Core where the <methodname>addDuplicateAlias</methodname> method would include an entry into the hash map even when the <varname>classAlias</varname> variable was set to null; causing a <exceptionname>NullPointerException</exceptionname> when the <methodname>CrazyJPARRequirements()</methodname> method is called. To correct this issue the <filename>FromClause.java</filename> file has been modified to correct the <methodname>addDuplicateAlias</methodname> method by testing if the <varname>alias</varname> variable is null and if it is not null then the <methodname>fromElementByClassAlias.put</methodname> is now called, instead of this method being called even if <varname>alias</varname> contained a null value. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1...;: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has expectly said that the version field should not be updated and does not update the field if this is the case. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1251">JBPAPP-1...;: 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-1...;: 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> + Though this is a significant fix to Hibernate, it has been included within this CP release because of its undeniable advantage to all users and ensures that filters on queries operate how a user would expect them to. + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>Security Issues</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1548">JBPAPP-1...;: 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. (CVE-2009-0027 ) + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>Documentation</title> + <para> + <itemizedlist> + <listitem> + <para> + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> + <title>Core Server</title> + <para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1636">JBPAPP-1...;: When an adapter handled the scheduling of work to be performed, the <classname>ExecutionContext</classname> class contains a value in seconds, from which the <methodname>getCompletionTimeout</methodname> method of <classname>org.jboss.resource.work.WorkWrapper</classname> obtains its information. An issue arises with <methodname>getCompletionTimeout</methodname> expecting the value to be in milliseconds, creating an error where the initially set timeout value may be 6 seconds but be passed to the thread pool as 6 milliseconds. The <filename>WorkWrapper.java</filename> file has been updated and correctly converts the timeout value from seconds to milliseconds. + </para> + <important> + <para> + This bug only affected third party adapters running within the JBoss Application Server. + </para> + </important> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1635">JBPAPP-1...;: The <classname>OracleExceptionSorter</classname> has been enhanced for this release with new error codes of 17002 (connection reset) and 17008 (connection closed) now able to be handled. These enhancements have been applied to the <filename>OracleExceptionSorter.java</filename> file. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1602">JBPAPP-1...;: A <exceptionname>ConcurrentModificationException </exceptionname> would occur when a classloader would be undeployed while another user was attempting to load a class from the package. This error arose because the <classname>packagesMap</classname> within <classname>UnifiedLoaderRepository3</classname> had a <classname>TreeSet</classname> that was not correctly synchronized with changes. In order to rectify this, the <filename>ClassLoaderUtils.java</filename> file has been updated to import the <classname>Collections</classname> library and use the <methodname>synchronizedSet</methodname> method of the library in returning the <methodname>TreeSet</methodname> of the <methodname>newPackageSet</methodname> method. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1540">JBPAPP-1...;: Within the cluster section of the EAP, the <classname>GossipRouter</classname> and <classname>GossipClient</classname> (TCPGOSSIP) did not have socket read timeouts, socket linger timeouts and backlog set to provide the best behaviour when heavily utilized or under network situations in need of improvement. This fix provides default values and configuration options for these in order to avoid problematic situations. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1539">JBPAPP-1...;: When running parallel instances of the EAP on Linux a bug existed where messages between the JGroups component of each instance would be picked up by both because all messages sent to the port number for Multicast Sockets would be picked up by both instances. The issue has been fixed by re-writing the code for Multicast Sockets so that the constructor uses a group address along with the port number as identifiers. This ensures that an instance of the EAP only receives messages pertaining to its specific group and thus inhibits channel crosstalk. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1538">JBPAPP-1... Probe Client had not been updated to use the same address as the Probe Listener does which is now 224.0.75.75. Correcting this issue, the Proble Client now uses 224.0.75.75 instead of 224.0.0.75 which allows the client and the listener to work together correctly. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1535">JBPAPP-1...;: The JDBCExtCacheLoader didn't handle persistent state transfter correctly since the <methodname>storeState</methodname> method would use avaliable space on the <classname>MarshalledValueInputStream</classname> instead of on the <classname>ByteArrayInputStream</classname>. To correct the stream usage, <filename>JDBCExtendedCacheLoader.java</filename> has been updated to store the new state using the <varname>in_stream</varname> value as long as there is space avaliable. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1534">JBPAPP-1...;: 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-1...;: 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-1...;: 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-1...;: 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-1458">JBPAPP-1...;: The JTA recovery configuration did not contain a line to enable JBoss Messaging (JBM) <classname>XAResourceRecovery</classname> even though it is stated in the JBM user guide. This CP release modifies the <filename>build-distr.xml</filename> file to all <classname>XAResourceRecovery</classname> to be enabled for JTA recovery. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1479">JBPAPP-1...;: 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> + This has been rectified in this release by modifying <filename>build.xml</filename> and <filename>login-config.xml</filename> to differentiate between requirements for each individial distribution. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1473">JBPAPP-1...;: The <classname>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</classname> within clustering didn't correctly call <classname>isHttpSessionListenerInvocationAllowed</classname>, which would lead to the repeated calling of itself and eventually <exceptionname>StackOverflow</exceptionname> errors. In order to correct this the <filename>IgnoreUndeployLegacyClusteredSessionNotificationPolicy.java</filename> file has been modified to correctly call <classname>isHttpSessionListenerInvocationAllowed</classname>. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1460">JBPAPP-1...;: The JavaServer Faces (JSF) has been updated to version 1.2_10 for this EAP release. This update corrects numerious bugs and details on these fixes can be found at <ulink url="https://javaserverfaces.dev.java.net/nonav/rlnotes/1.2_10/chang... + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1366">JBPAPP-1...;: Creation of the EJB <filename>TIMERS</filename> table fails when the <option>Oracle</option> schema is specified. To correct this the <filename>GeneralPurposeDatabasePersistencePlugin.java</filename> file has been updated with a calling to an new <methodname>SQLUtil.fixConstraintName</methodname> function which changes all dots in a constraint name to underscores. This ensures that constraint names are compatable with Oracle. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1307">JBPAPP-1...;: The Persistence Unit (PU) root was incorrectly detected within deployments that contained nested <filename>.jar</filename> files. The root PU was being detected as the first nested <filename>.jar</filename> encountered instead of being the deployment which contains the <filename>persistence.xml</filename> file. To make sure that the PU root is always set correctly, the <filename>JmxDeploymentUnit.java</filename> file has been updated with the removal of testing for the url being null and the <parameter>deploymentInfo.parent</parameter> not being null. This means that the url is now always taken straight from the <parameter>extractDescriptorUrl</parameter> of <filename>META-INF/persistence.xml</filename>. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1289">JBPAPP-1...;: 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-1...;: 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> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1267">JBPAPP-1...;: <classname>UserTransaction</classname> (UT) was not able to be deployed with a clustered proxy that supported sticky transactions correctly. This has been fixed by modifying numerious files which make <classname>UserTransaction</classname> deployable with transaction sticky load balance policies. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1249">JBPAPP-1...;: 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 &lt;h:dataTable&gt; 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 &lt;h:dataTable&gt; 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 &lt; 0) || (index &gt;= list.size())) { </code> to <code>if ((index &lt; 0) || (index &gt; 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-1...;: 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-1...;: 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-1...;: 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-1...;: 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-99...;: 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-71...;: 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-52...;: 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> + </itemizedlist> + </para> + </formalpara> + </section> + <section id="Known_Issues_with_this_release"> + <title> + Known Issues with this release + </title> + <para> + Following is a list of known issues at the time of release. + </para> + <itemizedlist> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1286">JBPAPP-1...;: Footnotes within documentation tables and lists do not appear within PDFs. This issue resides within FOP and currently no workaround exists. Where possible footnotes are not used in the circumstances mentioned, however in documents such as the Release Notes the web address of a JIRA is automaticly generated as a footnote and places a number beside that of the JIRA, referencing a footnote that does not appear. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-909">JBPAPP-90...;: Within the Hibernate component of the EAP the HashMap and HashSet iteration order changed from past releases because of support for JDK 1.6. However this has meant that the order of columns in union clauses and union-subclasses has changed, generating a slight impact on the components performance. + </para> + </listitem> + <listitem> + <para> + <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-885">JBPAPP-88...;: An issue exists where if <methodname>DefaultRedeliveryDelay</methodname> or <methodname>RedeliveryDelay</methodname> is set to a value apart from zero, messages will not be redelivered even though the method <methodname>session.rollback()</methodname> had been called. This issue will not be fixed because redelivery delay is handled on the server side and the message is already acknowledged before delivery of the message with a non durable subscription. For the Enterprise Application Platform, this means that redelivery delays with non durable subscriptions cannot be supported. + </para> + </listitem> + </itemizedlist> + </section> +--> +<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="Revision_History.xml"/> + +</article>