[jboss-cvs] JBossAS SVN: r90720 - projects/docs/enterprise/4.3.5/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Jun 30 20:37:03 EDT 2009
Author: irooskov at redhat.com
Date: 2009-06-30 20:37:03 -0400 (Tue, 30 Jun 2009)
New Revision: 90720
Modified:
projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
Log:
fixed spelling
Modified: projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
===================================================================
--- projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-07-01 00:04:58 UTC (rev 90719)
+++ projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-07-01 00:37:03 UTC (rev 90720)
@@ -394,7 +394,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1607">JBMESSAGING-1607</ulink>: When the <filename>bisocket-remoting-service.xml</filename> was updated in pervious releases, the <filename>sslbisocket-remoting-service.xml</filename> missed being updated accordingly. The following patameters were missing and have now been added in order to ensure remoting configuration functions correctly:
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1607">JBMESSAGING-1607</ulink>: When the <filename>bisocket-remoting-service.xml</filename> was updated in previous releases, the <filename>sslbisocket-remoting-service.xml</filename> missed being updated accordingly. The following parameters were missing and have now been added in order to ensure remoting configuration functions correctly:
</para>
<programlisting>
<attribute name="validatorPingPeriod" isParam="true">10000</attribute>
@@ -421,7 +421,7 @@
String channelName = (channelPartitionName != null)? channelPartitionName : groupName;
</programlisting>
<para>
- Where the difference is that the <varname>channelPartitionName</varname> is tested to not be null instead of being null. This ulteration ensures that the channel name is resolved correctly.
+ Where the difference is that the <varname>channelPartitionName</varname> is tested to not be null instead of being null. This alteration ensures that the channel name is resolved correctly.
</para>
</listitem>
<listitem>
@@ -436,12 +436,12 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1516">JBMESSAGING-1516</ulink>: Functionality has been added to the <classname>MessagingPostOffice</classname> where users can now perform changes to the <property>failoverOnNodeLeave</property> property in order to give administrators improved flexibility with whould should occur when a JBoss Messaging cluster node is shutdown under normal circumstances.
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1516">JBMESSAGING-1516</ulink>: Functionality has been added to the <classname>MessagingPostOffice</classname> where users can now perform changes to the <property>failoverOnNodeLeave</property> property in order to give administrators improved flexibility with what should occur when a JBoss Messaging cluster node is shutdown under normal circumstances.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1456">JBMESSAGING-1456</ulink>: Messages would not move from the <property>being-delivered</property> state when clients used a clustered XA connection factory in a cluster of at least two nodes without a restart of the servers. This was caused because when the client connection failed, the server side would not always be notified, which meant that messages would not be canceled and redelivered. To correct this behavior a new feature was added to the JBoss Remoting component to inable the necessary strict binding between a client and the server connection failure management. Correct synchronization is achieved through this, also fixing an issue of inaccurate message counts. The following new parameters have been introduced to the Remoting configuration file:
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1456">JBMESSAGING-1456</ulink>: Messages would not move from the <property>being-delivered</property> state when clients used a clustered XA connection factory in a cluster of at least two nodes without a restart of the servers. This was caused because when the client connection failed, the server side would not always be notified, which meant that messages would not be canceled and redelivered. To correct this behavior a new feature was added to the JBoss Remoting component to enable the necessary strict binding between a client and the server connection failure management. Correct synchronization is achieved through this, also fixing an issue of inaccurate message counts. The following new parameters have been introduced to the Remoting configuration file:
</para>
<programlisting>
<attribute name="failureDisconnectTimeout" isParam="true">0</attribute>
@@ -449,12 +449,12 @@
<attribute name="useClientConnectionIdentity" isParam="true">true</attribute>
</programlisting>
<para>
- This fix means that a customer can be asured that JBoss Messaging reliably delivers messages without missing data or discontinuity of the mission critical application.
+ This fix means that a customer can be assured that JBoss Messaging reliably delivers messages without missing data or discontinuity of the mission critical application.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1416">JBMESSAGING-1416</ulink>: The functionality of strict messaging has been added to the JBoss Messaging component. This allows for a user to determine an ordering group and only one message with the value of an ordering group is delieverd at once. After the message is acknowledged or cancelled the next message is delivered.
+ <ulink url="http://jira.jboss.com/jira/browse/JBMESSAGING-1416">JBMESSAGING-1416</ulink>: The functionality of strict messaging has been added to the JBoss Messaging component. This allows for a user to determine an ordering group and only one message with the value of an ordering group is delivered at once. After the message is acknowledged or cancelled the next message is delivered.
</para>
</listitem>
<listitem>
@@ -502,7 +502,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>
@@ -512,7 +512,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>
@@ -522,7 +522,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>
@@ -532,7 +532,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>
@@ -543,12 +543,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>
@@ -558,7 +558,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>
@@ -568,12 +568,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>
@@ -588,7 +588,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>
@@ -665,7 +665,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>
@@ -684,32 +684,32 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1974">JBPAPP-1974</ulink>: The optimisation within the <classname>JBossXSModel</classname> implementation for traversing a XML schema was insufficient, allowing for high deployment overhead when dealing with complex schemas. Correcting this has been a process of modifying the <filename>JBossXSModel.java</filename> file by adding calls to clear the <classname>HashSet</classname> periodically throughout the traversing process.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1974">JBPAPP-1974</ulink>: The optimization within the <classname>JBossXSModel</classname> implementation for traversing a XML schema was insufficient, allowing for high deployment overhead when dealing with complex schemas. Correcting this has been a process of modifying the <filename>JBossXSModel.java</filename> file by adding calls to clear the <classname>HashSet</classname> periodically throughout the traversing process.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1961">JBPAPP-1961</ulink>: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced <exceptionname>Denial of Service</exceptionname> attacks on a server that accpets XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1961">JBPAPP-1961</ulink>: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced <exceptionname>Denial of Service</exceptionname> attacks on a server that accepts XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1956">JBPAPP-1956</ulink>: The <classname>wscompile</classname> class would fail to create a valid package name when the namespace contained a capitalised reserved keyword. Rectifying this issue has seen the <filename>NameConverter.java</filename> file modified to include code that transforms all characters in the namespace to lower case. This fix also sees the upgrade of the JAXB component to 2.1.4.patch02; (see <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1982">JBPAPP-1982</ulink> for reference).
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1956">JBPAPP-1956</ulink>: The <classname>wscompile</classname> class would fail to create a valid package name when the namespace contained a capitalized reserved keyword. Rectifying this issue has seen the <filename>NameConverter.java</filename> file modified to include code that transforms all characters in the namespace to lower case. This fix also sees the upgrade of the JAXB component to 2.1.4.patch02; (see <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1982">JBPAPP-1982</ulink> for reference).
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1773">JBPAPP-1773</ulink>: Previously MTOM was only enabled for types annotated with <property>@XmlMimeType</property> where the content-type headers from the incoming messages should be sufficient to determine if MTOM is required. To fix this bug, MTOM has been enabled for incomming requests where the content type is <property>application/xop+xml</property>. To achieve this outcome both the <filename>MessageFactoryImpl.java</filename> and <filename>ServiceEndpointInvoker.java</filename> files have been updated to retrieve the message type and set the outbound context properties before calling the request handler chain respectively.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1773">JBPAPP-1773</ulink>: Previously MTOM was only enabled for types annotated with <property>@XmlMimeType</property> where the content-type headers from the incoming messages should be sufficient to determine if MTOM is required. To fix this bug, MTOM has been enabled for incoming requests where the content type is <property>application/xop+xml</property>. To achieve this outcome both the <filename>MessageFactoryImpl.java</filename> and <filename>ServiceEndpointInvoker.java</filename> files have been updated to retrieve the message type and set the outbound context properties before calling the request handler chain respectively.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1760">JBPAPP-1760</ulink>: If a substantial amount of SOAP requests were received by the JBoss Enterprise Application Platform during application deployment the <classname>HandlerResolverImpl</classname> class would cause a <exceptionname>ConcurrentModificationException</exceptionname>. Though this would not cause the application to cease opperation, it would result in the strage behaviour of every request going only through the JAXWS handler twice and not go into service implementation. In order to correct this bug, the code responsible for initiating handler chains within the <filename>HandlerDelegateJAXWS.java</filename> and <filename>HandlerDelegateJAXRPC.java</filename> has been synchronized.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1760">JBPAPP-1760</ulink>: If a substantial amount of SOAP requests were received by the JBoss Enterprise Application Platform during application deployment the <classname>HandlerResolverImpl</classname> class would cause a <exceptionname>ConcurrentModificationException</exceptionname>. Though this would not cause the application to cease operation, it would result in the strange behavior of every request going only through the JAXWS handler twice and not go into service implementation. In order to correct this bug, the code responsible for initiating handler chains within the <filename>HandlerDelegateJAXWS.java</filename> and <filename>HandlerDelegateJAXRPC.java</filename> has been synchronized.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1752">JBPAPP-1752</ulink>: The fault handler was not being called when user application exceptions were being generated. The implementation of the fault handler has been reworked for this Cummulative Patch release to catch the application exceptions and all other kinds of exceptions.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1752">JBPAPP-1752</ulink>: The fault handler was not being called when user application exceptions were being generated. The implementation of the fault handler has been reworked for this Cumulative Patch release to catch the application exceptions and all other kinds of exceptions.
</para>
</listitem>
<listitem>
@@ -719,13 +719,13 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1750">JBPAPP-1750</ulink>: SOAP 1.2 deployments are supported within JBoss Web Services, however the <classname>wsconsume</classname> tool does not support SOAP 1.2 bindings. To inable this tool to support SOAP 1.2, the files <filename>WSConsume.java</filename> and <filename>WSContractConsumer.java</filename> have been updated to recognise SOAP 1.2, while the files <filename>WSConsumeTask.java</filename> and <filename>SunRIConsumerImpl.java</filename> have been updated to set extensions. </para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1750">JBPAPP-1750</ulink>: SOAP 1.2 deployments are supported within JBoss Web Services, however the <classname>wsconsume</classname> tool does not support SOAP 1.2 bindings. To enable this tool to support SOAP 1.2, the files <filename>WSConsume.java</filename> and <filename>WSContractConsumer.java</filename> have been updated to recognize SOAP 1.2, while the files <filename>WSConsumeTask.java</filename> and <filename>SunRIConsumerImpl.java</filename> have been updated to set extensions. </para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1746">JBPAPP-1746</ulink>: <emphasis>Handler Chains</emphasis> did not work correctly within <emphasis>Dispatch</emphasis> clients causing incorrect behaviour. The dispatch component of Web Services has undergone extensive correction so that it works as a user would expect it to.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1746">JBPAPP-1746</ulink>: <emphasis>Handler Chains</emphasis> did not work correctly within <emphasis>Dispatch</emphasis> clients causing incorrect behavior. The dispatch component of Web Services has undergone extensive correction so that it works as a user would expect it to.
</para>
</listitem>
<listitem>
@@ -787,7 +787,7 @@
<itemizedlist>
<listitem>
<para>
- <filename>ReceiveUsernameOperation.java</filename> was updated with the removal of the operations for the <classname>Logger</classname> to aquire information about the <varname>username</varname> and <varname>password</varname> of the current <varname>user</varname> variable value.
+ <filename>ReceiveUsernameOperation.java</filename> was updated with the removal of the operations for the <classname>Logger</classname> to acquire information about the <varname>username</varname> and <varname>password</varname> of the current <varname>user</varname> variable value.
</para>
</listitem>
<listitem>
@@ -802,7 +802,7 @@
</listitem>
<listitem>
<para>
- <filename>AuthorizeOperation.java</filename> has been added to authenticate and check the authorisation of the current user.
+ <filename>AuthorizeOperation.java</filename> has been added to authenticate and check the authorization of the current user.
</para>
</listitem>
<listitem>
@@ -832,7 +832,7 @@
</listitem>
<listitem>
<para>
- <filename>WSSecurityDispatcher.java</filename> has been updated to remove the <classname>SecurityStore</classname> creater and now include private methods to decode the header and test authorization.
+ <filename>WSSecurityDispatcher.java</filename> has been updated to remove the <classname>SecurityStore</classname> creator and now include private methods to decode the header and test authorization.
</para>
</listitem>
<listitem>
@@ -868,7 +868,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>
@@ -890,7 +890,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>
@@ -936,7 +936,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>
@@ -971,7 +971,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>
@@ -1016,7 +1016,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>
@@ -1058,7 +1058,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>
@@ -1078,12 +1078,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 independent of Hibernate Annotations. This ensures that if a users wishes, Hibernate Validator does not have to be used with Hibernate Annotations.
</para>
</listitem>
</itemizedlist>
@@ -1095,12 +1095,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>
@@ -1134,12 +1134,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>
@@ -1156,7 +1156,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>
@@ -1171,17 +1171,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>
@@ -1191,7 +1191,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>
@@ -1201,7 +1201,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>
@@ -1211,7 +1211,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>
@@ -1241,7 +1241,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>
@@ -1291,7 +1291,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>
@@ -1311,12 +1311,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>
@@ -1346,12 +1346,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>
@@ -1370,7 +1370,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>
@@ -1380,7 +1380,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>
@@ -1425,7 +1425,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>
@@ -1437,7 +1437,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>
@@ -1453,13 +1453,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>
@@ -1564,7 +1564,7 @@
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1961">JBPAPP-1961</ulink>: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced <exceptionname>Denial of Service</exceptionname> attacks on a server that accpets XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1961">JBPAPP-1961</ulink>: A bug existed within Xerces that displayed a security vulnerability by permitting external entity definitions that produced <exceptionname>Denial of Service</exceptionname> attacks on a server that accepts XML data from external sources. In order to fix this issue, secure XML processing has now been implemented in JBoss Web Services wherever the document builder factory is constructed within the code.
</para>
<para>
This bug fix is part of the JBoss Web Services 2.0.1.SP2_CP06 upgrade.
@@ -1579,17 +1579,17 @@
<itemizedlist>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2059">JBPAPP-2059</ulink>: The <filename>JBoss Messaging User Guide</filename> has been updated with small additions throughout and a new final chapter that contains information on enablining the ordering group.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2059">JBPAPP-2059</ulink>: The <filename>JBoss Messaging User Guide</filename> has been updated with small additions throughout and a new final chapter that contains information on enabling the ordering group.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2011">JBPAPP-2011</ulink>: Documentation which explains how to achieve POJO Endpoint authentication in this latest CP release, has been incorporated into the <filename>Server Configuaration Guide</filename>. This information can be found in section <emphasis>10.13. POJO Endpoint Authentication and Authorization</emphasis>.
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-2011">JBPAPP-2011</ulink>: Documentation which explains how to achieve POJO Endpoint authentication in this latest CP release, has been incorporated into the <filename>Server Configuration Guide</filename>. This information can be found in section <emphasis>10.13. POJO Endpoint Authentication and Authorization</emphasis>.
</para>
</listitem>
<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>
@@ -1599,7 +1599,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>
@@ -1616,12 +1616,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"
@@ -1644,7 +1644,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