[jboss-cvs] JBossAS SVN: r90724 - projects/docs/enterprise/4.2.7/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Jun 30 20:56:16 EDT 2009
Author: irooskov at redhat.com
Date: 2009-06-30 20:56:16 -0400 (Tue, 30 Jun 2009)
New Revision: 90724
Modified:
projects/docs/enterprise/4.2.7/readme/en-US/Release_Notes_CP07.xml
Log:
corrected spelling
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-07-01 00:41:28 UTC (rev 90723)
+++ projects/docs/enterprise/4.2.7/readme/en-US/Release_Notes_CP07.xml 2009-07-01 00:56:16 UTC (rev 90724)
@@ -395,7 +395,7 @@
<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.
+ <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 occurrence 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>
@@ -405,7 +405,7 @@
</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.
+ <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 separate 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>
@@ -415,7 +415,7 @@
</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.
+ <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 available instead of only those in the configuration map.
</para>
</listitem>
<listitem>
@@ -425,7 +425,7 @@
</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.
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1112">JBREM-1112</ulink>: Upon a connection failure there was occurrences of a race condition occurring 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 unexpectedly. 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>Invok!
erLocator</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>
@@ -436,12 +436,12 @@
</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.
+ <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 parameters. 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.
+ <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. Correcting 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> that may have occurred.
</para>
</listitem>
<listitem>
@@ -451,7 +451,7 @@
</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.
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1102">JBREM-1102</ulink>: A feature was requested that would make the configuration map available 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>
@@ -461,12 +461,12 @@
</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.
+ <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 invokers 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.
+ <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>, enabling the actual exception content to be displayed to the user.
</para>
</listitem>
<listitem>
@@ -481,7 +481,7 @@
</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.
+ <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 configuration 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>
@@ -558,7 +558,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1873">JBPAPP-1873</ulink>: When the <parameter>LIMIT_BUFFER</parameter> parameter was set to <code>true</code> an <exceptionname>ArrayIndexOutOfBoundsException</exceptionname> would occur. The <filename>BodyContentImpl.java</filename> file has been updated to correct this bug by removing the <varname>bufferSizeSave</varname> variable and removing the case where the <varname>writer</varname> variable isn't null. To replace these a case has been written to execute the <methodname>clearBody</methodname> method when the <varname>writer</varname> variable is equal to null. By implementing these changes the <classname>JspWriter</classname> buffer size and remaning bytes are calculated correctly, removing the <exceptionname>ArrayIndexOutOfBoundsException</exceptionname>.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1873">JBPAPP-1873</ulink>: When the <parameter>LIMIT_BUFFER</parameter> parameter was set to <code>true</code> an <exceptionname>ArrayIndexOutOfBoundsException</exceptionname> would occur. The <filename>BodyContentImpl.java</filename> file has been updated to correct this bug by removing the <varname>bufferSizeSave</varname> variable and removing the case where the <varname>writer</varname> variable isn't null. To replace these a case has been written to execute the <methodname>clearBody</methodname> method when the <varname>writer</varname> variable is equal to null. By implementing these changes the <classname>JspWriter</classname> buffer size and remaining bytes are calculated correctly, removing the <exceptionname>ArrayIndexOutOfBoundsException</exceptionname>.
</para>
</listitem>
</itemizedlist>
@@ -613,7 +613,7 @@
</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.
+ <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 omitted 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, enabling use of the correct zone ID in each IPv6 address case.
</para>
</listitem>
<listitem>
@@ -635,7 +635,7 @@
</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.
+ <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 Cumulative 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>
@@ -669,7 +669,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/EJB-333">EJB-333</ulink>: A space was present in the path during deployment within the JBoss Eneterprise Application Platform and this space would cause an error. In order to fix this, the <classname>ExplodedJarVisitor</classname>, <classname>FileZippedJarVisitor</classname> and <classname>JarVisitorFactory</classname> classes have been updated to cater for a space in a java URL file name.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/EJB-333">EJB-333</ulink>: A space was present in the path during deployment within the JBoss Enterprise Application Platform and this space would cause an error. In order to fix this, the <classname>ExplodedJarVisitor</classname>, <classname>FileZippedJarVisitor</classname> and <classname>JarVisitorFactory</classname> classes have been updated to cater for a space in a java URL file name.
</para>
</listitem>
<listitem>
@@ -704,7 +704,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/EJB-284">EJB-284</ulink>: A bug existed within the <classname>ArchiveBrowser</classname> where it would not abstract a file path for <filename>orm.xml</filename> correctly when Hibernate was run on the Windows opperating system. In this new version of Hibernate EntityManager, the ArchiveBrowser has been replaced with the <classname>JarVisitor</classname>. This process has caused this issue to be fixed.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/EJB-284">EJB-284</ulink>: A bug existed within the <classname>ArchiveBrowser</classname> where it would not abstract a file path for <filename>orm.xml</filename> correctly when Hibernate was run on the Windows operating system. In this new version of Hibernate EntityManager, the ArchiveBrowser has been replaced with the <classname>JarVisitor</classname>. This process has caused this issue to be fixed.
</para>
</listitem>
<listitem>
@@ -749,7 +749,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/EJB-259">EJB-259</ulink>: <filename>ORM.xml</filename> files that appear in any referecend <filename>.jar</filename> files were not evaluated by Hibernate EntityManager. In order to be in line with the EJB3 specifications, the <classname>Ejb3Configuration</classname> class has been updated to make sure all <filename>ORM.xml</filename> files are evaluated.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/EJB-259">EJB-259</ulink>: <filename>ORM.xml</filename> files that appear in any referenced <filename>.jar</filename> files were not evaluated by Hibernate EntityManager. In order to be in line with the EJB3 specifications, the <classname>Ejb3Configuration</classname> class has been updated to make sure all <filename>ORM.xml</filename> files are evaluated.
</para>
</listitem>
<listitem>
@@ -791,7 +791,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/HV-7">HV-7</ulink>: Two level <property>@Valid</property> annotation did not work as a user would have expected. A <exceptionname>NullPointerException</exceptionname> would be generated when initialization occured in the <classname>ClassValidator</classname>. This bug has since been fixed by initializing the <classname>reflectionManager</classname> within the <classname>ClassValidator</classname> constructor.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/HV-7">HV-7</ulink>: Two level <property>@Valid</property> annotation did not work as a user would have expected. A <exceptionname>NullPointerException</exceptionname> would be generated when initialization occurred in the <classname>ClassValidator</classname>. This bug has since been fixed by initializing the <classname>reflectionManager</classname> within the <classname>ClassValidator</classname> constructor.
</para>
</listitem>
<listitem>
@@ -811,12 +811,12 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/HV-2">HV-2</ulink>: String suport for both <property>@Past</property> and <property>@Future</property> validating Strings has been deprecated as there was no absolute way to be sure of the date and time format or the locale that may be used.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/HV-2">HV-2</ulink>: String support for both <property>@Past</property> and <property>@Future</property> validating Strings has been deprecated as there was no absolute way to be sure of the date and time format or the locale that may be used.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/HV-1">HV-1</ulink>: A new feature has been added to Hibernate Validator that sets the <classname>ClassValidator</classname> as being independ of Hibernate Annotations. This ensures that if a users wishes, Hibernate Validator does not have to be used with Hibernate Annotations.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/HV-1">HV-1</ulink>: A new feature has been added to Hibernate Validator that sets the <classname>ClassValidator</classname> as being independant of Hibernate Annotations. This ensures that if a users wishes, Hibernate Validator does not have to be used with Hibernate Annotations.
</para>
</listitem>
</itemizedlist>
@@ -828,12 +828,12 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1930">JBPAPP-1930</ulink>: A <exceptionname>NullPointerException</exceptionname> would occur when a native SQL query coupled eager fetching with a many-to-many relationship. Correcting this has beant that the <code>if ( collectionPersister.isOneToMany() ) {</code> line of code in the <filename>SQLQueryReturnProcessor</filename> file has been changed to <code>if ( collectionPersister.isOneToMany() || collectionPersister.isManyToMany()) {</code>, removing the generation of a <exceptionname>NullPointerException</exceptionname>. To note though is that the fix only works with the <filename>hbm.xml</filename> file SQL mapping feature and a named query.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1930">JBPAPP-1930</ulink>: A <exceptionname>NullPointerException</exceptionname> would occur when a native SQL query coupled eager fetching with a many-to-many relationship. Correcting this has meant that the <code>if ( collectionPersister.isOneToMany() ) {</code> line of code in the <filename>SQLQueryReturnProcessor</filename> file has been changed to <code>if ( collectionPersister.isOneToMany() || collectionPersister.isManyToMany()) {</code>, removing the generation of a <exceptionname>NullPointerException</exceptionname>. To note though is that the fix only works with the <filename>hbm.xml</filename> file SQL mapping feature and a named query.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1922">JBPAPP-1922</ulink>: A bottleneck existed within the <filename>EntityModeToTuplizerMapping.java</filename> file when a high number of threads attempted to initialize sets and had to wait for the same monitor. In correcting this issue, the <filename>EntityModeToTuplizerMapping.java</filename> file has been modified to removie the <code>private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() ); </code> line of code and replace it with only <code>private final Map tuplizers;</code> and two new public methods to assist in the mapping.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1922">JBPAPP-1922</ulink>: A bottleneck existed within the <filename>EntityModeToTuplizerMapping.java</filename> file when a high number of threads attempted to initialize sets and had to wait for the same monitor. In correcting this issue, the <filename>EntityModeToTuplizerMapping.java</filename> file has been modified to remove the <code>private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() ); </code> line of code and replace it with only <code>private final Map tuplizers;</code> and two new public methods to assist in the mapping.
</para>
</listitem>
<listitem>
@@ -867,12 +867,12 @@
</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>.
+ <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 available 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.
+ <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 failures 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>
</itemizedlist>
@@ -889,7 +889,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-700">ANN-700</ulink>: The <classname>NamedQuery</classname> class of Hibernate had the <property>flushMode</property> attribute set to <property>AUTO</property> by default. This caused inconsistencies throught the program and the <property>flushMode</property> attribute to never contain the correct value. To correct this the default value of the <property>flushMode</property> attribute is now set to a newly introduced <property>PERSISTENCE_CONTEXT</property>. This new value makes sure that the <property>flushMode</property> is consistent with the persistence context at the time the query is executed, alleviating inconsistency issues.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-700">ANN-700</ulink>: The <classname>NamedQuery</classname> class of Hibernate had the <property>flushMode</property> attribute set to <property>AUTO</property> by default. This caused inconsistencies throughout the program and the <property>flushMode</property> attribute to never contain the correct value. To correct this the default value of the <property>flushMode</property> attribute is now set to a newly introduced <property>PERSISTENCE_CONTEXT</property>. This new value makes sure that the <property>flushMode</property> is consistent with the persistence context at the time the query is executed, alleviating inconsistency issues.
</para>
</listitem>
<listitem>
@@ -904,17 +904,17 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-696">ANN-696</ulink>: When a Hibernate map existed that had both <property>key</property> and <property>value</property> elements, the <property>@Type</property> annotation would affect both. To generate desired results the <filename>MapBinder.java</filename> and <filename>MapKey.java</filename> files have ben updated to include and use a <classname>MapKey</classname> <property>@Type</property>.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-696">ANN-696</ulink>: When a Hibernate map existed that had both <property>key</property> and <property>value</property> elements, the <property>@Type</property> annotation would affect both. To generate desired results the <filename>MapBinder.java</filename> and <filename>MapKey.java</filename> files have been updated to include and use a <classname>MapKey</classname> <property>@Type</property>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-695">ANN-695</ulink>: New Hibernate Search collection even listeners have been inegrated with the addition of the new classes <classname>CollectionSearchConfiguration</classname> and <classname>SearchConfiguration</classname>, and the ammendment of the <classname>AnnotationConfiguration</classname> class to use the new <classname>SearchConfiguration</classname> class instead of embedding the search functionality within the <classname>AnnotationConfiguration</classname>.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-695">ANN-695</ulink>: New Hibernate Search collection even listeners have been integrated with the addition of the new classes <classname>CollectionSearchConfiguration</classname> and <classname>SearchConfiguration</classname>, and the amendment of the <classname>AnnotationConfiguration</classname> class to use the new <classname>SearchConfiguration</classname> class instead of embedding the search functionality within the <classname>AnnotationConfiguration</classname>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-694">ANN-694</ulink>: An incorrect report of a Foreign Key circularity error was occuring when the <property>@*ToOne</property> property name started with the identifier property name. The issue has been fixed by modifying the <filename>ToOneFkSecondPass.java</filename> file to make the <methodname>ToOneFkSecondPass</methodname> method a public method.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-694">ANN-694</ulink>: An incorrect report of a Foreign Key circularity error was occurring when the <property>@*ToOne</property> property name started with the identifier property name. The issue has been fixed by modifying the <filename>ToOneFkSecondPass.java</filename> file to make the <methodname>ToOneFkSecondPass</methodname> method a public method.
</para>
</listitem>
<listitem>
@@ -924,7 +924,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-683">ANN-683</ulink>: When <property>hashCode</property> collisions occurred within <classname>AnnotationConfiguration</classname>, random binding failures would occur. To fix this issue, the <filename>FkSecondPass.java</filename> file has been updated to use a unique counter in order to differenciate between two instances of <classname>FkSecondPass</classname> so that they can be compared as the IBM VM would sometimes return the same <varname>hashCode</varname> for two different objects. The <filename>AnnotationConfiguration.java</filename> file has also been updated to utilize the changes made to <filename>FkSecondPass.java</filename>.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-683">ANN-683</ulink>: When <property>hashCode</property> collisions occurred within <classname>AnnotationConfiguration</classname>, random binding failures would occur. To fix this issue, the <filename>FkSecondPass.java</filename> file has been updated to use a unique counter in order to differentiate between two instances of <classname>FkSecondPass</classname> so that they can be compared as the IBM VM would sometimes return the same <varname>hashCode</varname> for two different objects. The <filename>AnnotationConfiguration.java</filename> file has also been updated to utilize the changes made to <filename>FkSecondPass.java</filename>.
</para>
</listitem>
<listitem>
@@ -934,7 +934,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-671">ANN-671</ulink>: When the <classname>Validator</classname> was not present, a message describing this would be logged, however this would occur twice. In this update the <classname>AnnotationConfiguration</classname> class has been modified to only log the occurance of this once for each time.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-671">ANN-671</ulink>: When the <classname>Validator</classname> was not present, a message describing this would be logged, however this would occur twice. In this update the <classname>AnnotationConfiguration</classname> class has been modified to only log the occurrence of this once for each time.
</para>
</listitem>
<listitem>
@@ -944,7 +944,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-650">ANN-650</ulink>: In previous versions the <classname>@Version</classname> class could be set withih an <classname>@Embedded</classname> class without any checking and generate a <exceptionname>java.lang.ArrayIndexOutOfBoundsException</exceptionname> that would not display enough detail about the error for a user to understand the cause. This has since be altered to check for this occurance and generate an <exceptionname>AnnotationException</exceptionname> with useful information so that a user can correct any issues.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-650">ANN-650</ulink>: In previous versions the <classname>@Version</classname> class could be set within an <classname>@Embedded</classname> class without any checking and generate a <exceptionname>java.lang.ArrayIndexOutOfBoundsException</exceptionname> that would not display enough detail about the error for a user to understand the cause. This has since be altered to check for this occurrence and generate an <exceptionname>AnnotationException</exceptionname> with useful information so that a user can correct any issues.
</para>
</listitem>
<listitem>
@@ -974,7 +974,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-619">ANN-619</ulink>: When <classname>@OneToOne</classname> was placed within a composite key, the Hibernate application would generate an <exceptionname>ExceptionInInitializerError</exceptionname>. This has been fixed by recoding how a user application that does not use a true <classname>OneToOne</classname> relationshipis tested.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-619">ANN-619</ulink>: When <classname>@OneToOne</classname> was placed within a composite key, the Hibernate application would generate an <exceptionname>ExceptionInInitializerError</exceptionname>. This has been fixed by recoding how a user application that does not use a true <classname>OneToOne</classname> relationships tested.
</para>
</listitem>
<listitem>
@@ -1024,7 +1024,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-556">ANN-556</ulink>: The <property>@OneToOne</property> relationship relied on strict alphebetical ordering that caused the <property>mappedBy</property> property to fail. The <classname>AnnotationBinder</classname> and <classname>AnnotationConfiguration</classname> classes have been updated to make sure that the <classname>OneToManySecondPass</classname> is processed in order.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-556">ANN-556</ulink>: The <property>@OneToOne</property> relationship relied on strict alphabetical ordering that caused the <property>mappedBy</property> property to fail. The <classname>AnnotationBinder</classname> and <classname>AnnotationConfiguration</classname> classes have been updated to make sure that the <classname>OneToManySecondPass</classname> is processed in order.
</para>
</listitem>
<listitem>
@@ -1044,12 +1044,12 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-552">ANN-552</ulink>: A major new feature for Hibernate Annotations is the transparent event registration and intergration for Hibernate Search and Hibernate Validator if they are in the classpath.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-552">ANN-552</ulink>: A major new feature for Hibernate Annotations is the transparent event registration and integration for Hibernate Search and Hibernate Validator if they are in the classpath.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-551">ANN-551</ulink>: Columns in a SQL insert query have to be ordered in the same way that Hibernate internally sorts its properties in order for the query to be successful. This was an issue for users as some would use numerious application servers, all of which would order these properties in different ways. The issue has been solved by modifying the <classname>AnnotationBinder</classname> class so that the parameters of a query are ordered internally to the order that Hibernate supports.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-551">ANN-551</ulink>: Columns in a SQL insert query have to be ordered in the same way that Hibernate internally sorts its properties in order for the query to be successful. This was an issue for users as some would use numerous application servers, all of which would order these properties in different ways. The issue has been solved by modifying the <classname>AnnotationBinder</classname> class so that the parameters of a query are ordered internally to the order that Hibernate supports.
</para>
</listitem>
<listitem>
@@ -1084,12 +1084,12 @@
</listitem> -->
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-529">ANN-529</ulink>: Hibernate used the optional keyword <emphasis>as</emphasis> in the from clause within the <classname>MapBinder</classname> class. This behavior caused Hibernate Annotations to not be compatable with Oracle 10g. The optional keyword is now removed from the from clause and Hibernate Annotations is successfully compatable with Oragle 10g.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-529">ANN-529</ulink>: Hibernate used the optional keyword <emphasis>as</emphasis> in the from clause within the <classname>MapBinder</classname> class. This behavior caused Hibernate Annotations to not be compatible with Oracle 10g. The optional keyword is now removed from the from clause and Hibernate Annotations is successfully compatible with Oracle 10g.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-525">ANN-525</ulink>: The <property>@ForeignKey</property> annotation that is used to specify readable names to foreign key constraints could not be applied at the class level and so could not be utilized in providing readable names to constrints between the super and sub classes using the <property>InheritanceType.JOINED</property> property. In this release the <property>@ForeignKey</property> annotation is now supported at the class level for all joined subclasses and is an attribute of the <classname>o.h.a.Table</classname> for secondary tables.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-525">ANN-525</ulink>: The <property>@ForeignKey</property> annotation that is used to specify readable names to foreign key constraints could not be applied at the class level and so could not be utilized in providing readable names to constraints between the super and sub classes using the <property>InheritanceType.JOINED</property> property. In this release the <property>@ForeignKey</property> annotation is now supported at the class level for all joined subclasses and is an attribute of the <classname>o.h.a.Table</classname> for secondary tables.
</para>
</listitem>
<listitem>
@@ -1108,7 +1108,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-509">ANN-509</ulink>: Using a foreign key value for the <property>referecedColumnName</property> value would cause a <exceptionname>MappingException</exceptionname> to occur. The reason for this issue has stemed through the need for correct ordering of steps and to fix this a <classname>RecoverableException</classname> class has been created which is used to catch the exception and allow the program to perform passes to assist in correcting the issue. If however this is unsuccessful then the loop is exited and the original exception is displayed to the user.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-509">ANN-509</ulink>: Using a foreign key value for the <property>referecedColumnName</property> value would cause a <exceptionname>MappingException</exceptionname> to occur. The reason for this issue has stemmed through the need for correct ordering of steps and to fix this a <classname>RecoverableException</classname> class has been created which is used to catch the exception and allow the program to perform passes to assist in correcting the issue. If however this is unsuccessful then the loop is exited and the original exception is displayed to the user.
</para>
</listitem>
<listitem>
@@ -1118,7 +1118,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-502">ANN-502</ulink>: Intergration with Hibernate Validator was not completely possible as it is used in metamodel construction and could not be disabled. In order to allow for this functionality the <property>hibernate.validator.apply_to_ddl</property> has been added and can be set to false to remove Hibernate Validator intergration with metamodel construction.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-502">ANN-502</ulink>: Integration with Hibernate Validator was not completely possible as it is used in metamodel construction and could not be disabled. In order to allow for this functionality the <property>hibernate.validator.apply_to_ddl</property> has been added and can be set to false to remove Hibernate Validator integration with metamodel construction.
</para>
</listitem>
<listitem>
@@ -1163,7 +1163,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-26">ANN-26</ulink>: Support for the ability to exculde a property from the optimistic locking has been added to Hibernate Annotations.
+ <ulink url="http://opensource.atlassian.com/projects/hibernate/browse/ANN-26">ANN-26</ulink>: Support for the ability to exclude a property from the optimistic locking has been added to Hibernate Annotations.
</para>
</listitem>
</itemizedlist>
@@ -1175,7 +1175,7 @@
</listitem> -->
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2032">JBPAPP-2032</ulink>: The Hibernate Annotations upgrade that has occured between the last JBoss Enterprise Application Platform Cummulative Patch and this one may cause backwards-compatibility issues for some users due to the changes introduced to applications that use <classname>SchemaExport</classname> in production. The following instances are circumstances where an issue may arise:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2032">JBPAPP-2032</ulink>: The Hibernate Annotations upgrade that has occurred between the last JBoss Enterprise Application Platform Cumulative Patch and this one may cause backwards-compatibility issues for some users due to the changes introduced to applications that use <classname>SchemaExport</classname> in production. The following instances are circumstances where an issue may arise:
</para>
<itemizedlist>
<listitem>
@@ -1191,13 +1191,13 @@
</itemizedlist>
<warning>
<para>
- If these concerns are not addressed by affected users then noticable data consistencies and performance issues may arise. The new configuration parameter <property>hibernate.legacy.foreignkey.use_identity_hashcode_to_compare</property> should also not be utilised as it will restore indeterminate behaviour.
+ If these concerns are not addressed by affected users then noticeable data consistencies and performance issues may arise. The new configuration parameter <property>hibernate.legacy.foreignkey.use_identity_hashcode_to_compare</property> should also not be utilized as it will restore indeterminate behavior.
</para>
</warning>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1859">JBPAPP-1859</ulink>: The <classname>ManyToOneJoinTest</classname> distributed with Hibernate would fail because a primary key would be set on a <code>nullable</code> column. The <filename>OneToOneSecondPass.java</filename> file has been modified to use the <methodname>buildJoinFromMappedBySide</methodname> method instead of the <methodname>buildJoin</methodname> method. Inacting this change has meant that the calls to the <methodname>join.createPrimaryKey()</methodname> and <methodname>join.createForeignKey()</methodname> methods within this file have also been removed.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1859">JBPAPP-1859</ulink>: The <classname>ManyToOneJoinTest</classname> distributed with Hibernate would fail because a primary key would be set on a <code>nullable</code> column. The <filename>OneToOneSecondPass.java</filename> file has been modified to use the <methodname>buildJoinFromMappedBySide</methodname> method instead of the <methodname>buildJoin</methodname> method. Enacting this change has meant that the calls to the <methodname>join.createPrimaryKey()</methodname> and <methodname>join.createForeignKey()</methodname> methods within this file have also been removed.
</para>
</listitem>
<listitem>
@@ -1301,7 +1301,7 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1782">JBPAPP-1782</ulink>: Chapter 7.2 named <emphasis>Adjusting memory settings</emphasis> within the <filename>Installation Guide</filename>, stated that a user should modify the <filename>run.conf</filename> file in order to increase the avaliable memory to the program. This however is incorrect when running the JBoss Enterprise Application Platform on a Windows operating system. In this case the <filename>run.bat</filename> file should be modified and the documentation now reflects this difference.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1782">JBPAPP-1782</ulink>: Chapter 7.2 named <emphasis>Adjusting memory settings</emphasis> within the <filename>Installation Guide</filename>, stated that a user should modify the <filename>run.conf</filename> file in order to increase the available memory to the program. This however is incorrect when running the JBoss Enterprise Application Platform on a Windows operating system. In this case the <filename>run.bat</filename> file should be modified and the documentation now reflects this difference.
</para>
</listitem>
<listitem>
@@ -1311,7 +1311,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1689">JBPAPP-1689</ulink>: The <filename>Server Configuration Guide</filename>, section 16.5 contained an error reguarding the name of the directory where JBoss Web is deployed. Instead of the path to the <filename>jboss-service.xml</filename> file being <filename>JBOSS_HOME/server/all/deploy/jbossweb-tomcat50.sar/META-INF/jboss-service.xml</filename> it should be <filename>JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml</filename>. For this CP release, the file path has been corrected.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1689">JBPAPP-1689</ulink>: The <filename>Server Configuration Guide</filename>, section 16.5 contained an error regarding the name of the directory where JBoss Web is deployed. Instead of the path to the <filename>jboss-service.xml</filename> file being <filename>JBOSS_HOME/server/all/deploy/jbossweb-tomcat50.sar/META-INF/jboss-service.xml</filename> it should be <filename>JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml</filename>. For this CP release, the file path has been corrected.
</para>
</listitem>
<listitem>
@@ -1328,12 +1328,12 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1976">JBPAPP-1976</ulink>: The <classname>HASingletonElectionPolicySimple</classname> class of the Clustering component retrieved the current view from the <classname>HAPartition</classname> and formulated a decision based on that information that ignored the possibility that the service being managed may nt be running on all cluster members. To fix this issue the <classname>ExtendedElectionPolicySimple</classname> class has been created and when used it fixes not only the above issue but also an issue where using the <code>kill -9</code> command was necessary to start singletons on other nodes. This new class extends the election policy and provides helper methods for stable implementations.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1976">JBPAPP-1976</ulink>: The <classname>HASingletonElectionPolicySimple</classname> class of the Clustering component retrieved the current view from the <classname>HAPartition</classname> and formulated a decision based on that information that ignored the possibility that the service being managed may not be running on all cluster members. To fix this issue the <classname>ExtendedElectionPolicySimple</classname> class has been created and when used it fixes not only the above issue but also an issue where using the <code>kill -9</code> command was necessary to start singletons on other nodes. This new class extends the election policy and provides helper methods for stable implementations.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1932">JBPAPP-1932</ulink>: Java 1.4 based clients would not function when trying to use the Java remote method invocation interface over the Internet Inter-Orb Protocol (RMI-IIOP). This occured because sections of placeholder code (which allow the program to function correctly) were needed, however these sections of code were compiled with Java 1.5 without compatibility for version 1.4. In order to correct this bug, the <filename>iiop/build.xml</filename> file has been updated with the removal of:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1932">JBPAPP-1932</ulink>: Java 1.4 based clients would not function when trying to use the Java remote method invocation interface over the Internet Inter-Orb Protocol (RMI-IIOP). This occurred because sections of placeholder code (which allow the program to function correctly) were needed, however these sections of code were compiled with Java 1.5 without compatibility for version 1.4. In order to correct this bug, the <filename>iiop/build.xml</filename> file has been updated with the removal of:
</para>
<programlisting>
<javac destdir="${build.classes}/main"
@@ -1356,7 +1356,7 @@
</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.
+ <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 excluded <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>
<listitem>
More information about the jboss-cvs-commits
mailing list