[jboss-cvs] JBossAS SVN: r89631 - projects/docs/enterprise/4.2.7/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jun 1 23:04:04 EDT 2009
Author: irooskov at redhat.com
Date: 2009-06-01 23:04:04 -0400 (Mon, 01 Jun 2009)
New Revision: 89631
Modified:
projects/docs/enterprise/4.2.7/readme/en-US/Release_Notes_CP07.xml
Log:
updated release notes with new JIRA
Modified: projects/docs/enterprise/4.2.7/readme/en-US/Release_Notes_CP07.xml
===================================================================
--- projects/docs/enterprise/4.2.7/readme/en-US/Release_Notes_CP07.xml 2009-06-02 03:00:50 UTC (rev 89630)
+++ projects/docs/enterprise/4.2.7/readme/en-US/Release_Notes_CP07.xml 2009-06-02 03:04:04 UTC (rev 89631)
@@ -366,14 +366,21 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1995">JBPAPP-1995</ulink>: The <methodname>RegionManager.createRegion</methodname> method would allow duplicate region names and when this occurs all future cache operations would happen only on the second instance of the region, while the <methodname>EvictionTimerTask</methodname> will only watch the first instance, causing the eviction queue of the second instance to fill. To correct this bug, the <methodname>RegionManager.checkConflict</methodname> method now counts a duplicate as a conflict and causes the <methodname>RegionManager.createRegion</methodname> method to generate an exception.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1993">JBPAPP-1993</ulink>: The JBoss Cache component of the Enterprise Application Platform has been upgraded to version 1.4.1_SP13. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1995">JBPAPP-1995</ulink>: The <methodname>RegionManager.createRegion</methodname> method would allow duplicate region names and when this occurs all future cache operations would happen only on the second instance of the region, while the <methodname>EvictionTimerTask</methodname> will only watch the first instance, causing the eviction queue of the second instance to fill. To correct this bug, the <methodname>RegionManager.checkConflict</methodname> method now counts a duplicate as a conflict and causes the <methodname>RegionManager.createRegion</methodname> method to generate an exception.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1994">JBPAPP-1994</ulink>: The <methodname>findNode</methodname> method of TreeCache generated a <exceptionname>NullPointerException</exceptionname> when the <methodname>findInternal</methodname> method returned a null value. The <methodname>findNode</methodname> method can now handle a null value returned from the <methodname>findInternal</methodname> method by checking within the <filename>TreeCache.java</filename> file if the <varname>toReturn</varname> value is null as well as the <varname>version</varname>
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
- <listitem>
- <para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1994">JBPAPP-1994</ulink>: The <methodname>findNode</methodname> method of TreeCache generated a <exceptionname>NullPointerException</exceptionname> when the <methodname>findInternal</methodname> method returned a null value. The <methodname>findNode</methodname> method can now handle a null value returned from the <methodname>findInternal</methodname> method by checking within the <filename>TreeCache.java</filename> file if the <varname>toReturn</varname> value is null as well as the <varname>version</varname>
- </para>
- </listitem>
</itemizedlist>
</para>
</formalpara>
@@ -383,8 +390,106 @@
<itemizedlist>
<listitem>
<para>
-
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1996">JBPAPP-1996</ulink>: The JBoss Remoting component of the Enterprise Application Platform has been upgraded to version 2.2.3. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1129">JBREM-1129</ulink>: It was possible for <emphasis>PING</emphasis> messages to arrive out of order because socket and bisocket transports use a pool of connections. To fix this bug when a <classname>org.jboss.remoting.Lease</classname> is created a timestamp is associated with it and carried by an initial <emphasis>PING</emphasis> message. The contents of an updated <emphasis>PING</emphasis> message will now be discarded if its timestamp is older than the previously processed timestamp. In the occurance that the initiating <emphasis>PING</emphasis> message does not have a time stamp, the lease will assume that the client is using an older version of JBoss Remoting and it will accept all updated <emphasis>PING</emphasis> messages.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1128">JBREM-1128</ulink>: Connection identity for the <classname>LeasePinger</classname> and <classname>Lease</classname> pair has been added by setting the parameter <property>org.jboss.remoting.Remoting.USE_CLIENT_CONNECTION_IDENTITY</property> to <emphasis>true</emphasis>. JBoss Remoting then identifies a connection with a <classname>LeasePinger</classname> and <classname>Lease</classname> pair and a client participates in a connection when it is connected by way of the new method <methodname>connect(ConnectionListener listener, Map metadata)</methodname>. This method serves to connect the client to the server by way of a new or existing client invoker, and it also registers the <classname>ConnectionListener</classname> with the client's new or exiting <classname>ConnectionValidator</classname>, while also registering the <classname>ConnectionValidator</classname> with the client invoker's <classname>LeasePinge!
r</classname>. Subsequently, if any <classname>ConnectionValidator</classname> registered with that <classname>LeasePinger</classname> detects a connection failure, it will (if the <property>stopLeaseOnFailure</property> parameter is set to <emphasis>true</emphasis>) stop the <classname>LeasePinger</classname>, and the <classname>LeasePinger</classname> will cause each registered <classname>ConnectionValidator</classname> to notify each of its registered <classname>ConnectionListeners</classname> of the connection failure. If a client is reconnected by a call to the <methodname>Client.connect()</methodname> method, it will be associated with a new <classname>LeasePinger</classname> and be treated as a new connection.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1127">JBREM-1127</ulink>: <exceptionname>ClassCastExceptions</exceptionname> would arise from the caching of <classname>Unmarsharller</classname> and <classname>Classloader</classname> in the <classname>MicroRemoteClientInvoker</classname> and performing classloading when accessing a remote bean from seperate isolated EARs. In fixing this issue the <filename>MicroRemoteClientInvoker.java</filename> file has been updated to modify the use of <methodname>useCurrentThreadClassLoader</methodname>, the variable <varname>useCurrentThreadClassLoader</varname> has been added to <filename>RemotingClassLoader.java</filename>, and <filename>JavaSerializationManager.java</filename> has been modified to update the <classname>ObjectInputStream</classname> classloader if the <varname>useCurrentThreadClassLoader</varname> variable of <classname>RemotingClassLoader</classname> has a value of true.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1125">JBREM-1125</ulink>: When a <classname>java.util.Timer</classname> class no longer had <classname>TimerTasks</classname> in its queue, it would allow itself to shut down. This behavior caused subsequent calls to the <methodname>Timer.schedule()</methodname> method to generate a <exceptionname>java.lang.IllegalStateException</exceptionname>. The exception has been overcome by modifying the <filename>AbstractDetector.java</filename> file to test for an <exceptionname>IllegalStateException</exceptionname> when scheduling on the <classname>heartbeatTimer</classname> and <classname>Timer</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1121">JBREM-1121</ulink>: Functionality has been added to the client <classname>SocketFactory</classname> that allows it to be configurable by the <classname>InvokerLocator</classname> so that all the parameters from the <classname>InvokerLocator</classname> are avaliable instead of only those in the configuration map.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1119">JBREM-1119</ulink>: If the application called the <methodname>org.jboss.remoting.Client.removeListener()</methodname> method, then <classname>ServerInvoker</classname> would remove references to <classname>ServerInvokerCallbackHandler</classname>, and it would call the <methodname>ServerInvocationHandler.removeListener()</methodname> method, granting the application a chance to remove the reference it held. An issue arose if the connection from the client was to break as that would cause none of the above to be executed, leading to a memory leak in the program. To fix the problem, <classname>ConnectionNotifier</classname> now uses copies of lists in order to avoid a <exceptionname>ConcurrentModificationException</exceptionname>, a <methodname>shutdown()</methodname> method has been added to the <classname>ServerInvokerCallbackHandler</classname>, and within the <classname>ServerInvoker</classname> the <metho!
dname>removeCallbackHandler()</methodname> method has been made public and a <methodname>shutdownCallbackHandler()</methodname> method has been added. These changes mean that the <methodname>shutdown()</methodname> method within the <classname>ServerInvokerCallbackHandler</classname> can be used by the application to remove the necessary references by utilizing the <classname>ServerInvoker</classname> and the applications <classname>ServerInvocationHandler</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1112">JBREM-1112</ulink>: Upon a connection failure there was occurances of a race condition occuring between the <classname>ConnectionValidator</classname> and <classname>ConnectionListener</classname> as <classname>ConnectionValidator</classname> may be able to execute the <methodname>Client.getDisconnectTImeout()</methodname> method before a <classname>ConnectionListener</classname> executes <methodname>Client.setDisconnectTimeout()</methodname>, causing the program to behave unexpectenly. This issue has been fixed by introducing a new parameter called <property>ConnectionValidator.FAILURE_DISCONNECT_TIMEOUT</property> (with the actual value of <varname>failureDisconnectTimeout</varname>). If the <property>org.jboss.remoting.Client.USE_ALL_PARAMS</property> property (with the actual value of <varname>useAllParams</varname>) is set to <emphasis>true</emphasis>, this parameter can be set in the <classname>Invoker!
Locator</classname>, the client's configuration map, or the metadata map passed to the <methodname>Client.addConnectionListener()</methodname> method. If <emphasis>failureDisconnectTimeout</emphasis> is set to an integer value other than -1, then <classname>ConnectionValidator</classname> will use that value when it calls the <methodname>ClientInvoker.terminateLease()</methodname> method, otherwise the value returned by the <methodname>Client.getDisconnectTimeout()</methodname> method is used.
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1111">JBREM-1111</ulink>: In <classname>LeasePinger</classname> when all the <classname>TimerTasks</classname> that ran in <classname>java.util.TimerTask</classname> were shut down the <classname>Timer</classname> would also shut down and will not accept any further <classname>TimerTasks</classname>. If a new <classname>Timer</classname> was to be created and a <classname>TimerTask</classname> scheduled for it, an exception would occur. In order to successfully replace the <classname>Timer</classname> if it has shut down, the <methodname>Wrapped timer.schedule()</methodname> is now utilized.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1110">JBREM-1110</ulink>: The method <methodname>org.jboss.remoting.InvokerLocator.getParameters()</methodname> would return null if the URL had no paramerters. In this updated release, the method returns an empty <varname>Map</varname> instead to ensure safer execution.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1109">JBREM-1109</ulink>: Within the <methodname>org.jboss.remoting.MicroRemoteClientInvoker.getDataType()</methodname> method when the <varname>dataType</varname> variable was set to the value of the <methodname>getDataType(getLocator())</methodname> method, the variable would temporarily be set to null if the <classname>InvokerLocator</classname> had no datatype parameter. This caused issues because another thread may use the <varname>dataType</varname> variable and return a value of null. Correting this bug has lead to using a local variable called <varname>localDataType</varname> while a check occurs to see if <classname>InvokerLocator</classname> contains a datatype value. The number of threads has also been reduced to 1000 in order to avoid an <exceptionname>OutOfMemoryError</exceptionname> taht may have occured.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1104">JBREM-1104</ulink>: When the <methodname>org.jboss.remoting.ident.Identity.get()</methodname> method would fail in a call to <methodname>InetAddress.getLocalHost()</methodname>, the runtime exception <exceptionname>java.lang.RuntimeException: Exception creating identity: myhost: myhost</exceptionname> would be generated. The issue was that the exception message did not give any information to the user concerning the underlying problem relating to the host name. This output has been fixed to display to the user the correct information in relation to the main host name issue.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1102">JBREM-1102</ulink>: A feature was requested that would make the configuration map avaliable to the <classname>marshalFactory</classname>. In order to support this the new parameter <property>org.jboss.remoting.Remoting.PASS_CONFIG_MAP_TO_MARSHAL_FACTORY</property> has been added, which requires a setting of <emphasis>true</emphasis> in order to have the configuration map passed to the <classname>marshalFactory</classname>. If the parameter contains a value of <emphasis>false</emphasis> then the original behavior will be executed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1100">JBREM-1100</ulink>: A feature was requested whereby <classname>ServerInvokerServlet</classname> instances could be linked to <classname>Connectors</classname> by MBean names rather than locator URLs. In order to achieve this the parameter <property>org.jboss.remoting.transport.servlet.ServletServerInvoker.CREATE_UNIQUE_OBJECT_NAME</property> has been added. When set to <emphasis>true</emphasis>, <methodname>ServletServerInvoker.getMBeanObjectName()</methodname> will call <methodname>org.jboss.remoting.ServerInvoker.getMBeanObjectName()</methodname> and return an <emphasis>ObjectName</emphasis> derived by the same algorithm that is used for all transports. To ensure the original default behavior remains, the default value is <emphasis>false</emphasis>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1099">JBREM-1099</ulink>: The multicast detector did not work correctly in environments where many JBoss Remoting invokers were being used. The <methodname>org.jboss.remoting.detection.AbstractDetector.createDetection()</methodname> method would create a detection message based on the number of server inokers registered locally. In the JBoss Enterprise Application Server this would cause an error as the message size would exceed the 4000 limit. A <property>buffersize</property> attribute has been created for <classname>org.jboss.remoting.detection.multicast.MulticastDetector</classname> and <classname>org.jboss.remoting.detection.multicast.MulticastDetectorMBean</classname> that defaults to a value of 10000.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1088">JBREM-1088</ulink>: If the server hostname DNS mapping was not available at the client during a <methodname>org.jboss.remoting.Client.connect()</methodname> call, the <methodname>org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName</methodname> produces a <exceptionname>java.net.UnknownHostException</exceptionname> in relation to the hostname. However when the method <methodname>MicroSocketClientInvoker(InvokerLocator locator, Map configuration)</methodname> is called the exception is captured and then displayed using <methodname>throw new RuntimeException(ex.getMessage())</methodname>. By displaying the exception in this way, information important in understanding the cause of the exception, is lost. This has been rectified by changing <methodname>throw new RuntimeException(ex.getMessage());</methodname> to <methodname>throw new RuntimeException(ex.getMessage(), ex);</method!
name>, enabeling the actual exception content to be displayed to the user.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1085">JBREM-1085</ulink>: The log level of the <methodname>ServerSocketWrapper.close()</methodname> method log messages has been reduced in order to remove unwanted information. Instead of using the <methodname>log.debug()</methodname> call, the method now uses <methodname>log.trace()</methodname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1084">JBREM-1084</ulink>: When <methodname>org.jboss.remoting.Client.addConnectionListener()</methodname> created a <classname>CallbackPoller</classname>, a reference to itself and a metadata map would be passed. The issue arose from the <classname>CallbackPoller</classname> only accessing parameters in the metadata map. To rectify this issue the <property>Client.USE_ALL_PARAMS</property> parameter is checked within the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map that is passed to the <methodname>Client.addListener()</methodname> method respectively. If the <property>useALLParams</property> property is found and set to a value of <emphasis>true</emphasis>, the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map will be searched respectively for all parameters used by <classname>CallbackPoller</classname>, otherwise only the metad!
ata map will be used, which is the default behavior.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1082">JBREM-1082</ulink>: When <methodname>org.jboss.remoting.Client.addConnectionListener()</methodname> created a <classname>ConnectionValidator</classname>, a reference to itself would be passed and the <classname>ConnectionValidator</classname> would access the client's configuration map. The issue arose from the client's configuartion map not including the <classname>InvokerLocator</classname> parameters. To rectify this issue the <classname>ConnectionValidator</classname> now searches for the <property>Client.USE_ALL_PARAMS</property> parameter in the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map that is passed to the <methodname>Client.addConnectionListener()</methodname> method respectively. If the <property>useALLParams</property> property is found and set to a value of <emphasis>true</emphasis>, the <classname>ConnectionValidator</classname> will search for pa!
rameter values in the <classname>InvokerLocator</classname>, the client's configuration map and the metadata map respectively.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1081">JBREM-1081</ulink>: When the method <methodname>ServerInvokerCallbackHandler.destroy()</methodname> shut down <classname>When org.jboss.remoting.callback.ServerInvokerCallback</classname>, the variables <varname>callBackClient</varname> and <varname>callbackStore</varname> were set to null. If the <methodname>ServerInvokerCallbackHandler.handleCallback()</methodname> is then called a <exceptionname>NullPointerException</exceptionname> arises because that variables <varname>callBackClient</varname> and <varname>callbackStore</varname> are set to null. This bug has been corrected in this latest release by the <methodname>ServerInvokerCallbackHandler.destroy()</methodname> method no longer assigning a value of null to the variables <varname>callBackClient</varname> and <varname>callbackStore</varname>.
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
@@ -425,6 +530,57 @@
</para>
</formalpara>
<formalpara>
+ <title>JGroups</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2002">JBPAPP-2002</ulink>: The JGroups component of the Enterprise Application Platform has been upgraded to version 2.4.6. A list of the included fixes is as follows:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JGRP-975">JGRP-975</ulink>: The JGroups testsuite did not permit a user to specify host and port properties for the <classname>GossipRouter</classname> implementation. This meant that the IP address was fixed at 127.0.0.1 and the port was fixed at 12001. This update allows for the host and port properties to be configurable so that the system can be tested against other values other than only the defaults.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JGRP-961">JGRP-961</ulink>: Running the JGroups testsuite against IPv6 addresses using <property>link-local</property> IPv6 addresses with no zone ID would cause some tests to fail that would normally pass when run against IPv4 addresses. The problem arose if the zone ID was ommitted and the OS assigned a default interface to send the message, which may not have been the one the user was after. To correct this issue so that IPv6 addresses worked correctly with JGroups, scoped <property>link-local</property> addresses had to be used with the <classname>ServerSocketReceiver</classname> and <classname>ServerSocketSender</classname> classes, enablining use of the correct zone ID in each IPv6 address case.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JGRP-949">JGRP-949</ulink>: Format version information was not displayed to the user in the most meaningful way. In order to make sure the the user receives the most useful information the way in which the format version information is provided has changed from:
+ </para>
+<programlisting>
+log.warn(new StringBuffer("packet from ").append(client_addr).append(':').append(client_port).append(" has different version (").append(version).append(") from ours (").append(Version.version).append("). This may cause problems"));
+</programlisting>
+ <para>
+ To:
+ </para>
+<programlisting>
+log.warn(new StringBuffer("packet from ").append(client_addr).append(':').append(client_port).append(" has different version (").append(version).append(") from ours (").append(Version.print(Version.version)).append("). This may cause problems"));
+</programlisting>
+ <para>
+ Of note is the change of <code>Version.version</code> to <code>Version.pring(Version.version)</code>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JGRP-923">JGRP-923</ulink>: GMS address printing did not contain the cluster name in the details it provided. For this Cummulative Patch release GMS address printing has been updated to include the cluster name in order to provide more detail to a user.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JGRP-893">JGRP-893</ulink>: Previously JGroups could not parse IPv6 addresses in the stack configuration correctly as it used a double colon (::) as a delimiter. These characters are now parsed correctly in JGroups so that IPv6 addresses can be used in a stack configuration correctly.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </formalpara>
+ <formalpara>
<title>JBoss Hibernate</title>
<para>
<itemizedlist>
@@ -445,6 +601,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1797">JBPAPP-1797</ulink>: Transient entities could be inserted twice when a merge was performed. To correct this bug the <filename>DefaultMergeEventListener.java</filename> file has been updated to use the new <classname>CopyCache</classname> class. Within the <filename>DefaultMergeEventListener.java</filename> file, logic has been added to retrieve transient entities and retry a merge once if an error is encountered. Following this, if the merge continues unsuccessfully a <exceptionname>TransientObjectException</exceptionname> will be generated. The <classname>CopyCache</classname> class has been created to be the <varname>Map</varname> implementation used by <classname>DefaultMergeEventListener</classname> in order to keep track of entities and the copies that are being merged into the session. This implementation also tracks whether a an entity in the <classname>CopyCache</classname> is included in the merge.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1748">JBPAPP-1748</ulink>: When merging read-only entities that had the <varname>@Immutable</varname> annotation included the following failure would occur:
</para>
<screen>
@@ -468,6 +629,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1564">JBPAPP-1564</ulink>: The SQL <methodname>trim</methodname> function and support for <property>mod</property> and <property>bit_length</property> were not present in the Sybase Dialect. This release sees these avaliable for use within the <filename>SybaseASE15Dialect</filename>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1563">JBPAPP-1563</ulink>: The SQL functions <function>mod</function>, <function>bit_length</function> and <function>trim</function> caused faulures in the <classname>ASTParserLoadingTest</classname> because they were not implemented in the Sybase Dialect. The Sybase Dialect has now been updated to import the <classname>org.hibernate.dialect.function.AnsiTrimEmulationFunction</classname> function and implement the <function>mod</function>, <function>bit_length</function> and <function>trim</function> functions.
</para>
</listitem>
@@ -486,8 +652,15 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1684">JBPAPP-1684</ulink>: A memory leak would be caused in the <classname>BaseTransaction</classname> class because entries in the hash table were never removed, even if a thread was no longer in use. This meant that client transactions could have leaked approximately 600 bytes. To correct this bug, the <filename>BaseTransaction.java</filename> file has been updated to replace the hash table with a <varname>ThreadLocal</varname> implementation which takes an integer as input. In order to allow for the timeout values to work correctly, they now only call the required methods of <methodname>_timeouts.set</methodname> and <methodname>_timeouts.get</methodname>. With these improvements made, the memory leak no longer occurs.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1693">JBPAPP-1693</ulink>: The JBoss Transaction Service component of the Enterprise Application Platform has been upgraded to version 4.2.3.SP5.CP05. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1684">JBPAPP-1684</ulink>: A memory leak would be caused in the <classname>BaseTransaction</classname> class because entries in the hash table were never removed, even if a thread was no longer in use. This meant that client transactions could have leaked approximately 600 bytes. To correct this bug, the <filename>BaseTransaction.java</filename> file has been updated to replace the hash table with a <varname>ThreadLocal</varname> implementation which takes an integer as input. In order to allow for the timeout values to work correctly, they now only call the required methods of <methodname>_timeouts.set</methodname> and <methodname>_timeouts.get</methodname>. With these improvements made, the memory leak no longer occurs.
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
@@ -563,6 +736,11 @@
forcing the <filename>build.xml</filename> file to use Java 1.4.
</para>
</listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1685">JBPAPP-1685</ulink>: Apache-slide has been upgraded to version 2.1.jdk15-brew. In this change is the renaming of <filename>jakarta-slide-webdavlib.jar</filename> to <filename>webdavlib.jar</filename> and the <filename>commons-httpclient.jar</filename> has been removed from the distribution because it was dependant on an unincluded <filename>commons-codec.jar</filename>. Removal of the <filename>commons-httpclient.jar</filename> file does not impact correct functioning of the JBoss Enterprise Application Platform.
+ </para>
+ </listitem>
</itemizedlist>
</para>
</formalpara>
@@ -590,6 +768,20 @@
<title>Hibernate Known Issues</title>
<para>
<itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1709">JBPAPP-1709</ulink>: The JPA spec defines the constant with a value that has a typo in the class name:
+ </para>
+ <programlisting>
+ javax.persistence.Persistence.PERSISTENCE_PROVIDER = "javax.persistence.spi.PeristenceProvider"
+ </programlisting>
+ <para>
+ The version of <filename>ejb3-persistence.jar</filename> released in EAP is non-compliant with the JPA spec because it sets the correct classname (without the typo) for this constant.
+ </para>
+ <para>
+ Javadoc for <methodname>javax.persistence.Query.getSingleResult()</methodname> says that the <exceptionname>EntityNotFoundException</exceptionname> will be generated if there is no result. The Javadoc should have mentioned the <exceptionname>NoResultException</exceptionname> instead.
+ </para>
+ </listitem>
<!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1613">JBPAPP-1613</ulink>: Null values for columns mapped as boolean in Hibernate, are persisted as zero instead of null. When the <methodname>PreparedStatement.setNull( index, java.sql.Types.BIT ) </methodname> method is executed in the Sybase environment, Sybase JDBC converts the null value to a zero because Sybase does not allow null bit columns.
More information about the jboss-cvs-commits
mailing list